 |
 | Home | Contact Us | FAQ | Search & Site Map | Link to Us |
 | Sign In | Join | Other 45 Sites in Network |
.NET Forum / Visual Studio.NET / Source Safe / March 2008Running SourceSafe on remote webserver
We're running SourceSafe on an internal server at my company but have been asked to look into running the server component on a webserver outside of our corporate network. We would use either Visual Studio or the SourceSafe client application to check files in/out. + Does SourceSafe allow the hosting of the server component somewhere other than the local network? (when I choose 'Add SS Database' the verbiage implies that the ini file I'm looking for is on the local network.) + Would the source code be available only to people whom we've set up as users or does hosting it outside of our firewall basically publish our source code? Alan Constantine's home page describes how to set this up: http://alinconstantin.homeip.net/webdocs/scc/VSS_Internet.htm But note there are some REALLY IMPORTANT items missing from his instructions (unless he's updated it recently). To save you a BUNCH of grief, here they are: - Each client user must have a Windows user account on the server (or an account in AD if your server is using AD). - Each client must *also* have a VSS account set up on the server. - The VSS user account must be named EXACTLY like the Windows account name for the user. - The VSS user account PASSWORD must be EXACTLY like the Windows account password. - When you create the Windows user account(s), make sure you set them so the passwords don't expire and so that the user is not required to change it on first log in. - You must give each VSS user full read/write permissions on the folder that contains the VSS database. - You need an SSL certificate on the server for secure communications. It will NOT work over HTTPS without a valid SSL certificate!!!! - You must access the VSS services via an HTTPS URL (secured URL). I would NOT do this without a secure connection!!! (not even sure if you CAN). - When accessing VSS server from VSS client over HTTP, you will have frequent write failures. Use the VSS client only for simple stuff like browsing projects, comparing versions, and labelling. Do NOT use it for transferring large quantities of files in or out of the server. It's EXTREMELY unreliable over HTTP(s). - If you use the VSS client, you must set up a "net use" to the path... something like: net use \\mydomain\myvssfolder / user:myvssusername * - Yes, you can do this with the VSS share over HTTP. Setting up your server creates a web folder, which you can "net use" across the internet... You can even browse if via Windows Explorer and any Windows application... It's just like connecting to a network share. - To access the VSS server over HTTPS from Visual Studio, you do NOT need to connect to a network share. File transfers between Visual Studio and VSS over HTTP seem to be totally reliable, unlike transfers between the VSS client and the server over HTTP(s). - When setting up your connection from within Visual Studio, it's confusing... REALLY confusing. After you point to the server via something like \\mydomain, then the path is \\localhost\myvssfolder. Seems odd, but you do have to reference the server as if you're locally on it. - You will frequently get $8000005 errors because for some reason, the HTTPS service on the server isn't responding for VSS requests. You'll have to remote control the server and bounce (restart) the HTTPS service. If you're running web sites on that same server, this will reset those web sites and lose any open sessions. - You may time out when going to the pending checkins tab in Visual Studio if you have a medium or larger solution. This may also happen if you're checking in a bunch of files. VSS over HTTP(s) is way way slower than over a LAN with a UNC connection. - Lastly (or firstly), you need to tell Visual Studio to use VSS over HTTP (tools, options, source control, change the drop down to "Microsoft Visual SourceSafe (Internet)". Hope this helps and GOOD LUCK! You're going to need it! You'll find that there's virtually ZERO help out there for this type of set up. Apparently, very few people are doing it, and I'm betting it's because it's so difficult to find informatoin on setting it up properly. Sometimes I think that I and Alan are the only 2 people on the planet using this feature... and I'm not so sure he's actually using it this way. -------------------------- Owner/Operator of www.MichaelsAttic.com > We're running SourceSafe on an internal server at my company but have > been asked to look into running the server component on a webserver [quoted text clipped - 9 lines] > as users or does hosting it outside of our firewall basically publish > our source code? engwar: As you may have seen from Mike's post, there is a lot to setup to allow Remote Access to SourceSafe. And even then you can only use a Visual Studio plugin to get to the VSS database. Another alternative you may want to investigate is SourceOffSite. The setup is a tad bit easier, and you can use either a SourceOffSite Explorer or Visual Studio to access your VSS databases. There is a free 30-day trial for the tool at http://www.sourcegear.com/sos HTH Jeff Clausius SourceGear > We're running SourceSafe on an internal server at my company but have > been asked to look into running the server component on a webserver [quoted text clipped - 9 lines] > as users or does hosting it outside of our firewall basically publish > our source code? Be careful with SourceOffSite. Check their bug fix history and make sure they've fixed the following bug: I used it around 2002~2003 and I confirmed the following: My settings were set to NOT delete my local data during check in. I checked in my code while I had Windows Explorer open to my source folder. I saw my files disappear one by one as they were checked in. Then I looked into the server and it failed to check them in. So, I had nothing checked in and it deleted my local copy. VERY Dangerous! I do realize that a lot of people have had success with this product, but I and my company stopped using it immediately after I was able to reproduce that fatal flaw (it was difficult to reproduce as it didn't do that every time). If it weren't for that, I'd highly recommend that product. Aside from deleting any chance of recovery of my source code, everything else about it was great, if you could afford the $350/ seat license fees. It was fast across our LAN and WAN and it worked across the internet (I think). VSS HTTP is extremely tricky to set up and is very very slow, but highly reliable and you don't have to spend money on a 3rd party product. Good luck with whichever product you choose to go with. -------------------------- Owner/Operator of www.MichaelsAttic.com > engwar: > [quoted text clipped - 27 lines] > > - Show quoted text - Mike: I've checked with Tech Support, and from what I can tell there's never been a bug logged for this? Did you contact our Tech Support department? Did they ever come to a resolution? You say you were able to reproduce the problem, although it was difficult. I know it may have been a while since you have used SourceOffSite (SOS), but we take reports of this kind very, very seriously, as SOS should never cause anyone to lose data. Since SourceOffSite has been in use by tens of thousands of people, I'm sure I would have heard of something as sever as this. I'd be more than happy to investigate further to see if we can help. Jeff Clausius SourceGear > Be careful with SourceOffSite. Check their bug fix history and make > sure they've fixed the following bug: [quoted text clipped - 22 lines] > Owner/Operator of > www.MichaelsAttic.com It's been more than 5 years and I was at a different company in a different city. They stopped using it because of that reproducible bug. The company I work for now does not use it. As best I can recall, it went like this: - SOS on a server on our WAN on same machine as VSS 6.0 DB. - VSS 6.0 Client and SOS client installed on my dev machine. - In SOS client, I had checked something like "do NOT delete local on check-in". - Then when I checked in, it failed AND it deleted my local files. So, the server copy was gone and so was my local copy. You may have to turn that check box on and off and check in multiple times to trigger it. It's as if the check box didn't stick on occasion. I can't recall if we ever reported it. I'm almost certain that we did, but again, it was 5 or more years ago. I hope this information is useful to you. > Mike: > [quoted text clipped - 40 lines] > > Owner/Operator of > >www.MichaelsAttic.com Mike: I've been unable to recreate this situation using SourceOffSite 4.2. As of right now, I'm closing the issue with our Tech Support dept as I've not been able to recreate the behavior. Thanks for the report. Jeff Clausius SourceGear > It's been more than 5 years and I was at a different company in a > different city. They stopped using it because of that reproducible [quoted text clipped - 58 lines] >>> Owner/Operator of >>> www.MichaelsAttic.com Unfortunately, it's been more than 5 years since this happened. Here's what I recall: - VSS 6.0 installed on a server. - SOS server component installed on same server... don't recall the version, but it was the latest at the time. - VSS 6.0, SOS client, and Visual Studio 6.0 installed on client machine. Server was Windows 2000 Server. My desktop was either NT 4.0 or XP... that was close to around the time we upgraded to XP, so I don't recall which version for sure, but it was more likely XP. - Working over a WAN from Chattanooga, TN to Portland, Maine. - In SOS client, I had checked and confirmed a box like "Do not delete local files on check in". - Using SOS client, I checked in my project, while having Windows Explorer opened to my local project folder. - SOS started "checking in" the files and they were systematically being deleted from my local machine. - When it was all done, I don't recall exactly what happened on the server... whether it deleted them on the server, or they never made it to the server, but the end result is they were gone from my local machine AND from the server. The first time this happened, I thought I must have mistakenly unchecked the box "do not delete local files on check in". From that point forward, I double-verified all of my settings and opened Windows Explorer (and backed up my files) before checking in and witnessed this happen 2 extra times. From that point forward, we never used it again. I've since upgraded my career and longer work at that company and have not used the product since, so sorry that I cannot give any more information than my 5 or 6 year old recollection. Note that I'm not asking for support and that I don't need it, since I'm not a customer. I will help you where I can though with my recollections. I think it's great that you take this type of report seriously. I see a later message that you created and subsequently closed a ticket. You might want to try recreating the environment I described above. I would also recommend having the developers take a deep look into the code that deletes locally and all conditions that could cause it to be called. I would also have them look at the logic when "delete local" is enabled and to avoid deleting until it is confirmed that the check in was successful. Have them look at what the code does when the check in fails (regarding deleting locally). Also, have them double-check that the server doesn't falsely report success on check in when it fails, thereby triggering the client to delete locally. It would probably be a good idea to not delete anything locally until every file in the project is checked in successfully. As a developer, a partially failed check in with a partially deleted project would cause me a lot of headache. I personally confirmed that these problems occurred and I would feel very uncomfortable using or recommending SOS until I knew that they verified and fixed the problem. As a matter of fact, I'd immediately buy the product because other than that serious flaw, it was by far a great solution for slow connections and over the internet connectivity. I'm a developer, so I do understand that problems that are difficult to reproduce are difficult to verify and hence to fix, so that's why I'm recommending that your developers peer directly into the code base, regardless of whether you're able to reproduce the problem. I have fixed many problems that I was never able to reproduce without ultimately searching in the code and finding where it *could* happen and fixing it. Usually, after finding it in code, I can then reproduce it because I know exactly what triggers it in the code. Of course, it's possible that the problem unintentionally got fixed as a side effect of other code changes. So, it might be worth checking out the version of your source that was publicly available in about 2000-2001. Hope this information is helpful! -------------------------- Owner/Operator of www.MichaelsAttic.com > Mike: > [quoted text clipped - 40 lines] > > Owner/Operator of > >www.MichaelsAttic.com Mike: Five years ago, I was working on the Vault Server, so I wasn't on the SOS client team at this time. However, we are investigating issues in SourceOffSite for future improvements, and I'm involved with this process. As I mentioned in my last post, I didn't uncover anything in the latest version of SourceOffSite. The code here has remained stable for a number of versions, including SOS 3.5. I'd be surprised if you were on that version or later, as the code here has been tested over and over, so it is pretty solid. We've never had a report of this kind for those versions. Regardless, I'll re-open up the ticket, add an audit of the code for checking in files to my currently assigned work items. Jeff Clausius SourceGear > Unfortunately, it's been more than 5 years since this happened. > Here's what I recall: [quoted text clipped - 112 lines] >>> Owner/Operator of >>> www.MichaelsAttic.com Very cool! I have to say: I am impressed with your willingness to check into the issue. The majority of software companies just assume their code is perfect and won't take problem reports seriously... especially in an informal setting such as this. I look forward to the progress reports... -------------------------- Owner/Operator of www.MichaelsAttic.com > Mike: > [quoted text clipped - 134 lines] > > - Show quoted text - Unfortunately, it's been more than 5 years since this happened. Here's what I recall: - VSS 6.0 installed on a server. - SOS server component installed on same server... don't recall the version, but it was the latest at the time. - VSS 6.0, SOS client, and Visual Studio 6.0 installed on client machine. Server was Windows 2000 Server. My desktop was either NT 4.0 or XP... that was close to around the time we upgraded to XP, so I don't recall which version for sure, but it was more likely XP. - Working over a WAN from Chattanooga, TN to Portland, Maine. - In SOS client, I had checked and confirmed a box like "Do not delete local files on check in". - Using SOS client, I checked in my project, while having Windows Explorer opened to my local project folder. - SOS started "checking in" the files and they were systematically being deleted from my local machine. - When it was all done, I don't recall exactly what happened on the server... whether it deleted them on the server, or they never made it to the server, but the end result is they were gone from my local machine AND from the server. The first time this happened, I thought I must have mistakenly unchecked the box "do not delete local files on check in". From that point forward, I double-verified all of my settings and opened Windows Explorer (and backed up my files) before checking in and witnessed this happen 2 extra times. From that point forward, we never used it again. I've since upgraded my career and no longer work at that company and have not used the product since, so sorry that I cannot give any more information than my 5 or 6 year old recollection. Note that I'm not asking for support and that I don't need it, since I'm not a customer. I will help you where I can though with my recollections. I think it's great that you take this type of report seriously. I see a later message that you created and subsequently closed a ticket. You might want to try recreating the environment I described above. I would also recommend having the developers take a deep look into the code that deletes locally and all conditions that could cause it to be called. I would also have them look at the logic when "delete local" is enabled and to avoid deleting until it is confirmed that the check in was successful. Have them look at what the code does when the check in fails (regarding deleting locally). Also, have them double-check that the server doesn't falsely report success on check in when it fails, thereby triggering the client to delete locally. It would probably be a good idea to not delete anything locally until every file in the project is checked in successfully. As a developer, a partially failed check in with a partially deleted project would cause me a lot of headache. I personally confirmed that these problems occurred and I would feel very uncomfortable using or recommending SOS until I knew that they verified and fixed the problem. As a matter of fact, I'd immediately buy the product because other than that serious flaw, it was by far a great solution for slow connections and over the internet connectivity. I'm a developer, so I do understand that problems that are difficult to reproduce are difficult to verify and hence to fix, so that's why I'm recommending that your developers peer directly into the code base, regardless of whether you're able to reproduce the problem. I have fixed many problems that I was never able to reproduce without ultimately searching in the code and finding where it *could* happen and fixing it. Usually, after finding it in code, I can then reproduce it because I know exactly what triggers it in the code. Of course, it's possible that the problem unintentionally got fixed as a side effect of other code changes. So, it might be worth checking out the version of your source that was publicly available in about 2000-2001. Hope this information is helpful! -------------------------- Owner/Operator of www.MichaelsAttic.com > Mike: > [quoted text clipped - 40 lines] > > Owner/Operator of > >www.MichaelsAttic.com Oh! I forgot to respond to the following: > And even then you can only use a Visual > Studio plugin to get to the VSS database. You can do a net use to the web share like this: net use \\mydomain.com\myVssFolder Or, if you like to use the old fashioned drive letters on your shares, you can assign a drive letter to it too. Then, you can access it just like you access a VSS database on your LAN... just crank up VSS client, add a database, browse to \\mydomain.com\myVssFolder (or the drive letter you assigned to the share), double click that INI file and you're good to go. Just don't use the client to check in large chunks of files. Feel free to use it to label, browse, and get files though. Uploading is just not all that reliable with the client... it's actually a flaw with MS's web-shared folders technology because web shares from SharePoint have the same problem. VSS access from within Visual Studio seems to be rock solid though (after you get passed the hair pulling configuration, that is!) Good Luck! And as Jeff said, try to go with SourceOffSite if they've fixed that particularly dangerous bug. One other recommendation: SourceVault. It's a totally different source code control product and much more powerful than VSS and works across the internet right out of the box... even has events so you can be notified the moment someone checks something in. The UI in their client looks an aweful lot like VSS, so if you're already familiar with VSS, you'll feel right at home. Unlike VSS, it has a seperate server component and is a true client-server product, where VSS is a client only product that stores it's stuff on a network share. -------------------------- Owner/Operator of www.MichaelsAttic.com > engwar: > [quoted text clipped - 27 lines] > > - Show quoted text - Hi engwar, You can also try Dynamsoft SourceAnywhere for VSS, the fastest VSS remote access software. It is recommended by Microsoft. For more information, please refer to: http://www.dynamsoft.com Thanks. Catherine Sea Dynamsoft Corporation  Signaturehttp://www.dynamsoft.com Hi engwar, You can also try Dynamsoft SourceAnywhere for VSS, the fastest VSS remote access software. It is recommended by Microsoft. For more information, please refer to: http://www.dynamsoft.com Thanks. Catherine Sea Dynamsoft Corporation Signaturehttp://www.dynamsoft.com Free MagazinesGet these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...
|
Reply to this Message
|
 Sign In
 Join
 My Latest Posts My Monitored Threads My Blog My Photo Gallery My Profile My Homepage Start New Thread Enable EMail Alerts Rate this Thread
|
©2008 Advenet LLC Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.