As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
Background: I'm a windows developer at MegaCorp(tm) and I am getting new hardware soon.
Question: Are there best practices around setting up my developer software installs?
Details: I've got my main IDE (Visual Studio/SQL Management Studio), but there are also tools that I'm testing out, additional tools I can't live without, and future accomodations.
All my code is stored on a remote server in SourceSafe so I don't need to really accommodate for that, but I'll regularly jump into perl/python/php for separate/side tasks.
The only advice I can give you is set up your machine in a way you need it and you can work with and then save an image so that you can return to that state easily.
Also, don't forget to go and get all your SysInternals goodies. Oh, also remember to export your rss feeds before you upgrade.
You should also install the Windows SDK (which usually doesn't come with VS), as there are many useful tools there that can help during development.
If you plan to use .NET, look into Reflector and LINQPad.
If you plan to use ASP.NET or do any web development at all, look into Fiddler and Firebug
Use a VM image, then the project has a VM image that is version controlled.
Tools and OS are recoverable years later.
Your name will shine on asa voice of sanity and configuration management.
Get rid of SourceSafe
Seriously, don't store anything in SourceSafe. There are many other, better Version Management Systems out there. What's wrong with SourceSafe? I strongly urge you to consider reading the following posts:
http://www.codinghorror.com/blog/archives/000660.html
http://www.highprogrammer.com/alan/windev/sourcesafe.html
http://www.developsense.com/testing/VSSDefects.html
Especially the last one - it goes into lots of detail about the problems with VisualSourceSafe. What should you use instead? Wikipedia has a great comparison of many different Version Management Systems for you to compare. You can look here to find out which ones integrate nicely with Visual Studio.
vim - VI Improved
Beyond Compare - best diff tool.
If you use multiple machines (like
one for dev one for test)
Synergy is invaluable.
If you occasionally need to edit
icons Paint.NET is pretty good.
As everyone else says kill source safe.
I have to agree regarding SourceSafe, whether or not you have the ability to opt-out of using it or not will obviously affect your ability to addopt a new SCM tool but if you can I highly recommenf the free VisualSVN Server for managing subversion and / or hosting repositories.
If you are prepared to pay for the licence you can also buy the VisualSVN plugin for visual studio, as a student I can't afford that but I have used AnkhSVN which integrates with VS through the source control provider APIs providing a nice native looking interface in VS 08
Other tools I can't live without:
TestDriven.NET
DocProject for easy generation of MSDN-style code documentation. I believe it uses sandcastle to do the real work but sandcastle itself is difficult to use and this is the most sane UI over it I've seen and managed to get working without massive amounts of work.
Paint.NET for graphics work
TortoiseSVN is another really good SVN client that I use for doing things like merging to trunk because I am more familiar with the interface and I think it's nicer than AnkhSVN in some areas
Related
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 12 years ago.
I am considering getting VSS and was wondering what were people's thoughts on it in particular?
It's well-known to corrupt data. There are many better alternatives. If you need to match the feature-set and GUI, check out Vault from SourceGear. Free alternatives are numerous --- from the ubiquitous svn to the more modern (distributed) git, mercurial, etc.
Also, TFS is the MS replacement -- if you want MS tools, at least use TFS.
Jeff Atwood has a nice post: Anything But SourceSafe
There is no excuse for using VSS when there are other solutions such as SVN, Git and Mercurial which are better both in terms of reliability and use more modern approach then VSS.
My thoughts:
AHHHHHHHHHRHRHRHGGGEHAGTJH##$#!&#&$!&###!##%^##$%
No. Seriously.
Before I knew how evil it was (newbie dev), I used it. Then, it corrupted an entire project I was working on. What a pile of garbage.
Use Subversion, Git, or Mercurial...for your own sanity.
Microsoft is pushing Team Foundation Server (TFS) as a replacement for VSS. VSS does offer the simplicity of a file based system, but you will spend a good amount of time repairing the database every so often. TFS is a much more reliable server based system. Visual Studio 2010 comes with a client license and a up to 5 person server license of TFS. You are better off putting your money there.
TFS Costs.
Because the question is a license/price issue, you can call 1-800-426-9400, Monday through Friday, 6:00 A.M. to 6:00 P.M. (Pacific Time) to speak directly to a Microsoft licensing specialist, and you can get more detail information from there.
Use TFS, Perforce, or maybe git.
Even if SourceSafe wasn't extremely dangerous to use (corruption, mentioned already)... just having file versions for source control really sucks. It's almost unbelievable that this type of source control is still widely used.
You want changeset or task-based source control. You'll want to easily know what files went into a specific change... not just a bunch of independently incrementing file numbers.
Perforce is VERY fast, and I'm very happy with it.
I use TFS for one major client, and it's been pretty good too. At the time I set up Perforce, TFS required a Server OS and license for that somewhere. I didn't want to have to set up yet another VM, so I went with Perforce.
I'd still easily choose Perforce today, though. That's mostly because I work with multiple platforms. As the main Perforce GUI client uses Qt, it looks and works the same on any OS.
VSS might be the right answer for some situations (e.g.: small group of devs using visual studio, not generally doing concurrent dev, fault tolerant env. (back-ups), etc.). I think the more important question is how your version control fits into your overall dev & release process. VSS and git are conceptually very different things in some very important ways and how your SDLC works is an important aspect of choosing a control system.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 11 years ago.
I'm writing this as DevConnections in Las Vegas is happening. Visual Studio 2010 has been released and I now have this 3GB beast installed to my machine. (I'll admit, it has some nice features.)
However, while the install was monopolizing my computer's resources I began to wish that my IDE worked more like Google Documents (instantly available, available anywhere, easy to share, easy to collaborate, naturally versioned).
A few Google (and StackOverflow) searches led me to :
Coderun
Bespin
I'm well aware that these IDE's are missing a lot of what exists in VS 2010. However, that isn't my question. Instead, I'm wondering what benefits a web-based IDE might have? Assuming a company invests the time to create the missing features, what is the downside?
Benefits:
Code available anywhere an internet connection is available
Simple sharing mechanisms
Simplified build mechanism
Many modern IDE features available (Autocomplete, syntax highlighting, etc...)
Requires a modern browser
Drawbacks:
Code is only available where an internet connection is available
Requires a modern browser (this might be an issue in some corporate settings)
Simplified build mechanism
At the mercy of the latency gods
No native debugger
No choice of revision-control
No clear backup solution
No clear way to fully remove source code from the provider's servers
No support available
No choice over maintenance schedule of servers
No control over IDE or environment features and tools
Must trust provider's security and privacy controls
As you can see, many of its benefits are also potential drawbacks. So I think the use of a browser-based IDE is very project dependent.
However, IMHO, I don't think browser-based IDEs have enough features or provide enough necessary services to replace desktop IDEs in most modern enterprises.
Just being devils advocate here and listing the disadvantages:
Disconnection!
The fact that you don't really own any software - if you stop paying the monthly bills you can't access it any more but you can keep using offline installed products after the initial payment.
Big / valuable projects may be uncomfortable not having their source code tucked away inside a network they control - one hacked account and their main IP is out on the net.
Limited extension ecosystem - with online services there is generally a control over it like facebook for example, but nobody tells resharper what features they can include
Forced upgrade - big corporations are still running .net 2.0 (.net 4 just came out). They can be slow to move and being forced to use the latest and greatest version of the app could be a too fast a pace for them.
Exposed to bugs - some people have wierd personal rules like they dont touch v1 software. If you always have the latest version you are exposing yourself to being hit by productivity consuming errors (security updates are a different category to feature updates but still if you are running desktop software you can isolate your security exposure and decide your own reasons to upgrade)
Interoperability - perhaps your app works with another app - they might not be able to keep up with the release pace of the main app and the interoperability functionality might lag while the other developers play catch up.
Centralised point of failure - no control over backups, redundancy, etc - its in the hands of the developers of the service.
Personally I find cloud based services very convenient and as time goes on now that I have a laptop and a desktop and a work computer and my friends have computers it becomes a chore to sync data between the lot. At the current stage we are still dealing with toy apps on the web but hopefully in a few years Silverlight will put a big dent in that.
The web is inheritly less featureful than a native application. Also, how do you compile and test out your code? No sane web host will let strangers compile, run, and test their code on their servers.
Besides "ubiquitous" availability (note the quotes), you get the "benefit" of editing code on the server. So, you get to skip many of the deployment steps that are necessary for many server side apps today. There's a simplicity of editing code like you'd edit a blog, but it can also be a curse as well. You still need a way to separate development from production.
But that said, if you use the Blog or many CMS applications, millions of folks use "Web based IDES" every day, so there's obviously applicability for specific application areas. I can tell you there are times I wish fixing a quick bug on a deployed app were as simply as clicking an "edit" button.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 10 years ago.
Given I'm:
a solo developer using VS2008 Professional
looking for Microsoft-produced source control (I'm aware there are alternatives)
looking to get away from Visual SourceSafe 2005
Is it correct that my only option is to drop ~$8k on Visual Studio Team System 2008 Development Edition ($5,469) + Team Foundation Server ($2,799) - in order to get the TFS version control component?
Reading the answers to other related questions it looks like routes to bringing the TFS price down is to either become a Microsoft Gold Certified partner or to take advantage of the ISV Empower program. I'd welcome any comments related to these options.
The top non-Microsoft solution looks to be Subversion + VisualSVN, but I'd really like to go the all-Microsoft route if I can possibly swing it.
The reason that I'd like to go all-Microsoft is that it's my preference to first try the stock solution, and then later try the alternatives with the benefit of that experience. Also, I've had the rare positive experience with SourceSafe. Or, maybe I'm just a closet MS fanboy. :-)
Also, does the picture change at all when VS2010 comes out?
Thanks!
P.S. I'm downloading VisualSVN now to give that a shot since there's no reason not to.
If you qualify for BizSpark, that comes with TFS.
Given you are an independent developer, and although I fully understand you wish to go the full-on Microsoft route, I can't stress highly enough that using one over the other won't mean as much to you at this point.
When I started using Source Control, I used VSS... much like many others on this site. After about 4 months, I quickly realized that there were many issues with it (namely, that it corrupted every 10 days or so, and that it caused my machine to lag horribly.)
I switched over to SVN and I do have to admit, I'm quite happy with the outcome. When you build your devleopment team to 2,3,4,5... then look into the expense. You'll find that you can get the same affect of Team Suite if you integrate SVN with something like fogbugz, or look at something like CodeSpaces
If you are a solo developer you might not need to go the TFS way. As the product name suggests it is for teams. I suggest take a dive into source control systems like Subversion + TortoiseSVN or Mercurial + TortoiseHg. You could even use a web based source control if it fits your needs, sometime like Launchpad.net
If you would say why you are so hip on getting it from Microsoft, we might better be able to help you?
Give SVN a try. Look at TortoiseSVN, AnkhSVN, and Visual SVN.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
We're thinking of switching to SVN at my work, so I was wondering about SVN plugins for VS2008 (and 2010 when it comes out). After a bit of research I found AnkhSVN and VisualSVN, the 2 that seemed most dominant. (I am aware of TortoiseSVN and will use the plugin in conjunction with it).
I am aware that this has been asked before, but these questions were asked almost a year ago and we all know that a lot of things can change in a year.
The question: From your experience, which is better and why?
Granted, it has been a year since I've used each product head-to-head, but my current preference is AnkhSVN. Though folks grumbled about early versions of AnkhSVN, 2.0 was a near rewrite of the original and is now a full Source Control Provider Integration Package rather than a Visual Studio Add-In. With commercial backing from CollabNet and renewed open source enthusiasm, AnkhSVN 2.0 deserves a chance.
My two favorite features of AnkhSVN are it is free and I love the Pending Changes window.
As for VisualSVN, I find it to be sluggish and I feel it leverages TortoiseSVN rather than handling the file management itself far too often. And it costs money (albeit a small amount.)
Again, this is based on my last head-to-head test which was about 1 year ago. As already stated, TortoiseSVN is great on it's own, but if you really want to plug into the VS IDE, give AnkhSVN a whirl before VisualSVN. Best of luck.
I have tried both of the VS plugins...after several months of use I quickly realized that I spent ALL of my time in Tortoise! The plugins don't get all of my trunk related items. They only work with items that are part of the solution and that VS recognizes. For this reason I spent pretty much all of my time in Tortoise...and eventually all of my time. There is no reason to pay for plugins when Toroise is both free and updated almost daily.
Stick with Tortoise and learn how to use it. You will be happier in the end.
Responses:
#jeroenh: "... There really is an advantage of using a (properly integrated) VS plugin, namely when moving/renaming files in your solution. ..."
I agree that renaming/moving files in Tortoise is clumsy. And VisualSVN does make this easier.
#Darko Z: "on a personal level I agree, but on an organisational level I don't. We have a few people here that NEED VS integration. Yeah its silly but fair enough :)"
Yes, I have several people like that in my current team. And training them to get used to Tortoise has been a Bear! They are the reason that we got some licenses for VisualSVN..but they complained about that too.
I had the same dilemma as well a few months ago, and finally decided to go with VisualSVN. We've been using it for 4 months for C# inhouse web application development and our experience has been positive.
Firstly, the server part integrates with Active Directory and offers an easy to use MMC control for managing the repositories.
Secondly, the client part integrates with VS2008, doesn't slow down Visual Studio loading times, and works with pretty trivial color codes (green for untouched files, yellow for files you changed). It features full revision diff's, you can comment every revision.
One down side is that its supports for hooks (like post-commit hooks) is very rudimentary.
You can view statistics like who made the most commits, etc. It supports branches although we don't use those features. All client-server communication is done through SSL (keys and certificates are configured automatically).
I asked them a question at some point about how to delete the branch history from the Visual Studio dropdown, and their support answered that I simply needed to delete the .suo file (efficient customer service)
Finally, my experience from working with VisualSVN: simple and straightforward for our relatively small team. (we're 5 programmers, but I'm pretty sure this scales a lot more than that).
I use VisualSVN at the moment, and it's great as it auto-adds any new files to the SVN and allows easy revert and diff without having to open an explorer window. However, you will still need to use TortoiseSVN for files not in your Visual Studio solution.
Last time I used AnkhSVN it didn't work too well and screwed my SVN checkout up (but this was a couple years ago).
I have used both and prefer Visual SVN (as of v3.0.4) because of its integration with Tortoise SVN which I already use and am quite familiar with. Because of this familiarity and VisualSVN's integration with it I prefer it a bit more.
I believe there is argument that AnkhSVN (as of v2.4.11610) has more features integrated into VS.NET, but it is working with it's own dialog windows and prompts which are not hard to get used to, but again I liked the functionality and familiarity of Tortoise SVN.
Also since all of my shop uses Tortoise SVN via Windows Explorer, the transition to Visual SVN ins't such a big deal other than adding the nice integration directly into VS.NET. I suffered none of the pitfalls commented in the other posts here (most are from 3-4 years ago it seems) when I used VisualSVN over the last 30 days.
So here is what I say: if you are a heavy user of Tortoise SVN and like how it works, go with VisualSVN. If you are new to Subversion and really don't care, then going with the free AnkhSVN with its additional integrated features is probably the way to go.
That question you asked boils down to personal preference but I would advise you to have IN ADDITION to the ide client either Tortoise SVN or the command line client. You will often be forced into positions where the IDE client cannot perform the task you need.
As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.
Closed 9 years ago.
I want to implement an "automatic update" system for a windows application.
Right now I'm semi-manually creating an "appcast" which my program checks, and notifies the user that a new version is available. (I'm using
NSIS for my installers).
Is there software that I can use that will handle the "automatic" part of the updates, perhaps similar to Sparkle on the mac? Any issues/pitfalls that I should be aware of?
There's now a Windows port of Sparkle, see http://winsparkle.org.
There is no solution quite as smooth as Sparkle (that I know of).
If you need an easy means of deployment and updating applications, ClickOnce is an option. Unfortunately, it's inflexible (e.g., no per-machine installation instead of per-user), opaque (you have very little influence and clarity and control over how its deployment actually works) and non-standard (the paths it stores the installed app in are unlike anything else on Windows).
Much closer to what you're asking would be ClickThrough, a side project of WiX, but I'm not sure it's still in development (if it is, they should be clearer about that…) — and it would use MSI in any case, not NSIS.
You're likely best off rolling something on your own. I'd love to see a Sparkle-like project for Windows, but nobody seems to have given it a shot thus far.
Google Chrome auto-update is based on Omaha:
http://code.google.com/p/omaha/
Their overview has a great section on why it was needed:
The browser typically prompted the user with a long series of techy, confusing and scary dialogs all trying to convince the user not to install. Then the user was prompted with a wizard filled with choices that they did not need to or know how to decide amongst. These factors combined to form a bad user experience and large drop-off during the app installation process
It's a good idea to use a third-party solution, cause autoupdates can be a pain, especially with Windows Vista/7 (UAC). For what it's worth, the product my company uses is AutoUpdate+ and it seems to work fairly well.
For .NET, a while back Microsoft Patterns + Practices published the Application Updater Block. This was (to my mind) rather overblown and over-engineered, but did the job quite well.
In essence it used a "stub loader" to check a manifest and a Web service to see if a later version of the program than the one installed was available, then used the BITS background downloader technology to download a new version if one was available on the server.
Once the new version was downloaded and installed (with .NET this is as simple as an xcopy to the relevant folder), the application would update the manifest. The next time the program was loaded the new version would be launched.
While the Patterns + Practices code is .NET specific, there's nothing there that couldn't be copied for a non-.NET application, especially if you have the ability to silently run the install process in the background.
If your application is written in .Net, you could try ClickOnce. However, it's difficult to perform administrative or custom actions during install using this approach.
wyUpdate looks really nice. See video here:
http://wyday.com/wybuild/help/automatic-updates/
For .NET applications you might want to have a look at NetSparkle, a Sparkle variant for .NET programs. It is pretty new (from 2011) and developed actively.
Just came here from an answer to my own question on the same subject - I mention one other updating solution in my question. It uses a stub loader, and an xml file to point to the latest executable.