Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
As a long-time Visual SourceSafe user (and hater) I was discussing switching to SVN with a colleague; he suggested using Git instead. Since, apparently, it can be used as peer-to-peer without a central server (we are a 3-developer team).
I have not been able to find anything about tools that integrate Git with Visual Studio, though - does such a thing exist?
What are the technologies available for using Git with Visual Studio? And what do I need to know about how they differ before I begin?
In Jan 2013, Microsoft announced that they are adding full Git support into all their ALM products. They have published a plugin for Visual Studio 2012 that adds Git source control integration.
Alternatively, there is a project called Git Extensions that includes add-ins for Visual Studio 2005, 2008, 2010 and 2012, as well as Windows Explorer integration. It's regularly updated and having used it on a couple of projects, I've found it very useful.
Another option is Git Source Control Provider.
I use Git with Visual Studio for my port of Protocol Buffers to C#. I don't use the GUI - I just keep a command line open as well as Visual Studio.
For the most part it's fine - the only problem is when you want to rename a file. Both Git and Visual Studio would rather that they were the one to rename it. I think that renaming it in Visual Studio is the way to go though - just be careful what you do at the Git side afterwards. Although this has been a bit of a pain in the past, I've heard that it actually should be pretty seamless on the Git side, because it can notice that the contents will be mostly the same. (Not entirely the same, usually - you tend to rename a file when you're renaming the class, IME.)
But basically - yes, it works fine. I'm a Git newbie, but I can get it to do everything I need it to. Make sure you have a git ignore file for bin and obj, and *.user.
Git Source Control Provider is new plug-in that integrates Git with Visual Studio.
I've looked into this a bit at work (both with Subversion and Git). Visual Studio actually has a source control integration API to allow you to integrate third-party source control solutions into Visual Studio. However, most folks don't bother with it for a couple of reasons.
The first is that the API pretty much assumes you are using a locked-checkout workflow. There are a lot of hooks in it that are either way expensive to implement, or just flat out make no sense when you are using the more modern edit-merge workflow.
The second (which is related) is that when you are using the edit-merge workflow that both Subversion and Git encourage, you don't really need Visual Studio integration. The main killer thing about SourceSafe's integration with Visual Studio is that you (and the editor) can tell at a glance which files you own, which must be checked out before you can edit, and which you cannot check out even if you want to. Then it can help you do whatever revision-control voodoo you need to do when you want to edit a file. None of that is even part of a typical Git workflow.
When you are using Git (or SVN typically), your revision-control interactions all take place either before your development session, or after it (once you have everything working and tested). At that point it really isn't too much of a pain to use a different tool. You aren't constantly having to switch back and forth.
I find that Git, working on whole trees as it does, benefits less from IDE integration than source control tools that are either file based or follow a checkout-edit-commit pattern. Of course there are instances when it can be nice to click on a button to do some history examination, but I don't miss that very much.
The real must-do is to get your .gitignore file full of the things that shouldn't be in a shared repository. Mine generally contain (amongst other stuff) the following:
*.vcproj.*.user
*.ncb
*.aps
*.suo
but this is heavily C++ biased with little or no use of any class wizard style functionality.
My usage pattern is something like the following.
Code, code, code in Visual Studio.
When happy (sensible intermediate point to commit code, switch to Git, stage changes and review diffs. If anything's obviously wrong switch back to Visual Studio and fix, otherwise commit.
Any merge, branch, rebase or other fancy SCM stuff is easy to do in Git from the command prompt. Visual Studio is normally fairly happy with things changing under it, although it can sometimes need to reload some projects if you've altered the project files significantly.
I find that the usefulness of Git outweighs any minor inconvenience of not having full IDE integration but it is, to some extent, a matter of taste.
Microsoft announced Git for Visual studio 2012 (update 2) recently. I have not played around with it yet, but this video looks promising.
Here is a quick tutorial on how to use Git from Visual Studio 2012.
Also don't miss TortoiseGit...
https://tortoisegit.org/
There's a Visual Studio Tools for Git by Microsoft. It only supports Visual Studio 2012 (update 2) though.
Visual Studio 2013 natively supports Git.
See the official announcement.
The Git support done by Microsoft in Visual Studio is just good enough for basic work (commit/fetch/merge and push). My advice is just to avoid it...
I highly prefer GitExtensions (or in less proportion SourceTree). Because seeing the DAG is for me really important to understand how Git works. And you are a lot more aware of what the other contributors to your project have done!
In Visual Studio, you can't quickly see the diff between files or commit, nor (add to the index) and commit only part of modifications. Browse your history is not good either... All that ending in a painful experience!
And, for example, GitExtensions is bundled with interesting plugins: background fetch, GitFlow,... and now, continuous integration!
For the users of Visual Studio 2015, Git is taking shape if you install the GitHub extension. But an external tool is still better ;-)
TortoiseGit has matured and I recommend it especially if you have used TortoiseSVN.
The newest release of Git Extensions supports Visual Studio 2010 now (along with Visual Studio 2008 and Visual Studio 2005).
I found it to be fairly easy to use with Visual Studio 2008 and the interface seems to be the same in Visual Studio 2010.
The simplest solution that actually works quite well is to add the TortoiseGit commands as external tools.
Solution to adding a Git (TortoiseGit) toolbar to Visual Studio
As mantioned by Jon Rimmer, you can use GitExtensions. GitExtensions does work in Visual Studio 2005 and Visual Studio 2008, it also does work in Visual Studio 2010 if you manually copy and config the .Addin file.
Currently there are 2 options for Git Source Control in Visual Studio (2010 and 12):
Git Source Control Provider
Microsoft Git Provider
I have tried both and have found 1st one to be more mature, and has more features. For instance it plays nicely with both tortoise git and git extensions, and even exposed their features.
Note: Whichever extension you use, make sure that you enable it from Tools -> Options -> Source control -> Plugin Selection for it to work.
As of 2013-02-11, the Microsoft Git plugin for Visual Studio 2012 should work with the Express version as well.
I noticed within the past couple of weeks my latest builds of a specific project are not showing up in Add/Remove programs.
I am using Visual Studio 2010, Windows7 64-bit (though I've also tried this over two Windows 32-bit machines). All latest service packs and updates are installed. The solution is made up of several projects with various references. The Setup and Deployment project is not the Install Shield version, but the one built in Microsoft project.
Previous versions of the software install fine, and still do... But if I pull down a tagged earlier version from CVS, and rebuild the installer for those versions, they do not work either.
I've opened the MSI in Orca, and I can see that the ARPNOREMOVE, ARPSYSTEMCOMPONENT are both set to 1. When the project gets installed, a registry entry SystemComponent Dword value is created. If I remove that registry entry, the application shows up. Based on everything I've read and researched I have found people that WANTED this functionality, but were told that Visual Studio can't do this on its own. Their solutions were to use Orca to add the ARPNOREMOVE or ARPSYSTEMCOMPONENT. At this point, all of the people who I found had my problem either had a basic default installer and they didn't know what name they were looking for in Add/Remove Programs or some other basic error that doesn't apply in my situation.
I've tried all of the following:
-Previous versions of tagged versions on CVS
-Multiple development machines
-Multiple computers to verify none show up in Add/Remove programs
-Resetting all Visual Studio settings
-Building from a clean development environment
-Removing Installer project from the solution and creating a new installer project
The weird part is that if I create a new solution and just create a setup and deployment project within, that installs fine. Can anyone having any idea about this help me out ?
So this is what I found out. We are using National Instruments Measurement Studio for .Net and the legacy controls. When using the legacy controls a certain merge module gets recognized as a dependency. For whatever reason, now this merge module change the behavior of the installer that is compiled. I've contacted National Instruments and am now working with them.
First, yes, you figured out the correct property name. Yes, ARPSYSTEMCOMPONENT is it which leads to an "unvisible" install under Add/Remove programs (ARP for insiders, although the name has changed post XP).
And it is possible to set/change the resulting "SystemComponent" entry in registry later which is not the case for all properties.
ARPNOREMOVE just controls if the uninstall in ARP is really possible to perform.
I have looked into Visual Installer before really, because it is so limited for MSI experts, but after taking a quick look there is a .vdproj (project file) created with VS 2010, and not very surprisingly, all the MSI information is coded there. The visual setup editors you can see in the solution explorer are only a subset.
Just look for "ARP" and you will find some properties set. The meanings of the values are maybe not so easy to guess, but from a rational point of view:
Either there is some setting inside there or a custom action (listed there too) which sets that property!
In my minimal test with the wizard only the ARPCONTACT property was set in the resulting msi file.
At least you could take the .vdproj file cor diffs with other checkedin versions..
I am trying to update an application using the Install Shield project in visual studio 2012.
I have read tons of articles/stackoverflow questions about it, and every single one gives the same steps for updating an existing application:
Increment product version
Change Product Code
Build Setup
So I do exactly that. First I build my application, then I build the setup. I find the setup, and I run it. It installs the application as expected.
Then I make a minor change to my application (changing the background color for example), then I:
I build the application
Increment Product version from 1.00.0000 to 1.00.0001
Change the Product Code - I Click the {...} to automatically generate a new one
Make sure the Update Code is the same
Build the setup
Go to the same directory I found the setup in before, and run the setup. It indicates that it installs, but then when I run the program, it is the original program - and in my Control Panel > Programs, there is now 2 instances of the application. And in the install directory of the application, it is still the original files.
I have clicked the resequence RemoveExistingProducts, and still the same thing.
edit: I am just using the basic version of InstallShield that came with VS2012
Anyone have any ideas what I am doing wrong? I have absolutely no idea what I am doing wrong...
As stated within the Upgrade Paths section of InstallShield within VS2012:
If you have released earlier versions of your product and you want to ensure that end users are able to upgrade to the current version without manually installing the earlier version and then also installing the current version, use the Upgrade Paths view to indicate upgrade information.
So in order to upgrade any previous installations, you need to add your application's Upgrade Code to the 'Upgrade Paths'. You can do this from the Solution Explorer:
[InstallShield Setup Project] -> Organize Your Setup -> Upgrade Paths
From that tab, you will right-click on the 'Upgrade Paths' option on the left side of the center pane, and select 'New Upgrade Path...'. You will then be presented with an option to select an installer (.exe or .msi) for your project which will populate the Upgrade Code field. Make sure you set the Min and Max Version fields to specify which versions of your application that you'd like your new installer to upgrade. If you'd like the new installer to upgrade any installed version of your application, then simply set the 'Include Max Version' and 'Include Min Version' fields to no.
You should now be set to build your solution, and when running the new installer, you'll find that you will no longer run into the problems you've specified.
a couple of weeks ago I made a small application which comes with the Installer, done with V.S.2010 tool. Now I need to upgrade the application, but I'd to deploy it as an update of the previous one.
How should I do? Is there some online doc that I can follow?
Unless you used OneClick technology for your Installer, Visual Studio does not support Install "Updates".
You will need to resend the entire Setup first, ask the user to remove the old one first (you can force this in the Setup project)
If you install the new updatedApp without forcing removing and without installing, it will overwrite all files that the new updateApp has.
I downloaded the team explorer 2005 and when I tried to open the application from source control , I am getting the error .csproj applicaion type is not installed.
How can I resolve this ?
In order to open a .csproj you will need to install a version of Visual Studio that supports .csproj`s. There are free versions, called express SKU's, of Visual Studio that should help you out here. It, and the other express SKU's, are available at the following link
http://www.microsoft.com/express/Windows/
You need a CAL (Client Access License) to run just team explorer and access the TFS functionality to check in and check out and other things. If you're wanting to open the projects and make changes you'll need a license for visual studio. There are many different options there. I don't believe you can use the free one in your situation. Using VS professional you'll still need to get the CAL as well to access TFS but if you get one of the team editions of VS you will have the TFS CAL included.
That's how I understand the licensing for TFS/VS but I'm not an expert and it would probably be best to ask your supplier or microsoft about licensing.
I believe Team Explorer allows one to interface with TFS which includes accessing project documentation, filing bugs, and possibly retrieving source code. However, I believe you need Visual Studio to open up project/solution files (i.e. a developer task).
This might be different with Visual Studio 2010 but that's the sales pitch we heard regarding 2008.
In summary, although you need the specific module that loads C# projects. When you installed Team Explorer, although you have the basic IDE, that module is not loaded (is similar to when you install SQL Server client - you have the Visual Studio IDE, but the only module loaded is the SQL Server management Studio). As some of the other guys suggested, try to install Visual Studio C# Express (you can find more information here - http://www.microsoft.com/express/Windows/ - click on Microsoft® Visual C#® 2008 Express Edition). Notice that later on if you want to use web application, you will need to install the web edition and so forth.
When you install Visual Studio Professional (or Team Suite) most of those modules are installed by default.
I hope this info helps.