I have been working with VS10 for years and yesterday I have installed VS12 side-by-side with the old one. Now I noticed that some file associations are inconsistent. Projects are opened by the version selector, C++ files by VS10 and FSX files with VS12 and more of this mess is around. Everything is a bit random and I wanted to map everything to VS12 while still having VS10 installed as I use XNA and you know that VS12 has no official support for XNA yet.
Searching SO revealed I only have to go to Options > General > Restore File Associations, but it is called now Manage File Associations and the control panel is being opened and lets me choose for every available format of VS which one I want:
I could select the check box to select all available formats but... I dislike this idea, because it could probably break something.
Has anyone good advice whether my doubts are wrong - yet how should I manage the associations without breaking anything?
That is a pretty fundamental limitation in the way file associations work in Windows. It works well when you click a solution or project file. They are associated with a little utility named VSLauncher.exe. Which looks in the file for the format version and thus knows which version of VS to start.
That same trick doesn't work for a source code file, like a .cpp or .cs file. There isn't enough information in the file to reliably pick a VS version. It is just code, most of which will compile properly on any recent VS version. So it is just associated with whatever version of VS you installed last.
Related
I want to version my visual studio 2010 debug builds. I'm going to use git. Right now all the project files are in 'project' and the output binaries are put by visual studio in the directory 'project\debug'. I've read a few questions on here that have ignore lists for Visual Studio but most of them have an ignore list that ignores the binary files, like the obj exe idb pdb ilk etc.
If I want to be able to debug my exe in the future what files do I need to keep? Is there any reason to keep the obj files? Does VS use them at all during debugging or tracing a crash? I thought I should keep at least the the pdb files and the exe. So that would be project.exe, project.pdb and vc100.pdb. But what about vc100.idb, project.ilk, project.res... etc. Is there an ignore list that will ignore everything that isn't needed to keep binary builds but keep everything that is?
I want to make sure if a user sends me a crash dump or reports a problem at some point in the future that I can go back to the version that was being used and be able to debug it. I had also hoped to make the binaries and debug files available in a remote repo so that anyone else could as well. Thanks!
Don't keep binaries in version control. Instead, build from source.
Since the binaries are built from source, and you have the source versioned already, just re-build the particular version as-needed. It will both keep your version control system lean and fast, as well as not cause merge headaches (which binaries are notorious for).
So, the answer is don't keep any binaries in version control.
If you feel you really must keep them, however, then just zip them up and store them like normal files using the tag of the build they came from.
I'm going to keep project.exe and project.pdb in the branch. The other files like *.obj, *.ilk, and *.sdf are not needed. Neither are the vc100.* files. I made my decision after speaking to a number of people in person and reviewing this:
File Types Created for Visual C++ Projects
and this:
Which Visual C++ file types should be committed to version control?
Although that SO question/answer does not answer my question it gave me a lot of good information. I also looked through my project.pdb for all the file references to confirm which files in my project that I needed to keep around. I used this command from the debugging tools for windows:
srcsrv\srctool -r project.pdb
Sometimes I've seen a solution that includes up to three .csproj files for each project in the solution. Something like this:
Project.UI.2005.csproj
Project.UI.2008.csproj
Project.UI.2010.csproj
and the same with .sln files:
ProjectSolution.2005.sln
ProjectSolution.2008.sln
ProjectSolution.2010.sln
So if you copy the solution and want to open it using VS2005, you just need to open Project.UI.2005.csproj or ProjectSolution.2005.sln.
What is the best way of creating those 3 (or 2) files, in order to be able to open the same solution in multiple versions of Visual Studio?
Maybe the only way of doing this is modifying manually the .sln/.csproj. If so:
How can I modify those files correctly so I won't crash the solution?
I want to do this because sometimes I develop applications using VS2010 and when deploying the source code to my customers, they can't open it in VS2008, and then I have to do some tweaks.
Note:
I know there will be referencing and compiling problems if I use features only included in .NET Framework v4.0, or similar. Let's suppose all the projects in the solution are compiling under .NET Framework 2.0 (specified in the project properties).
I finally ended developing a small application do to this.
I'm still testing it, but it is working good so far.
All you need to do is, select the .sln file you want to convert, and specify the versions involved in the conversion, and it will do all the work for you.
If you have a VS 2010 project:
Solution (Solution.sln)
Project_1 (Project_1.csproj)
Project_2 (Project_2.csproj)
and you want downgrade the version (to 2008), it will keep those files, and also create:
Solution.2008.sln
Project_1.2008.csproj
Project_2.2008.csproj
And you will be able to open Solution.2008.sln with Visual Studio 2008 without problems.
As soon as I finish it, I'll share executables and sources here.
I'm trying to use visual studio 2010. But it seems that the .sln file that is created through it isn't supported by previous versions. Is it possible to save the projects in a way that it could be readable by previous versions of visual studio (2008).
The accepted answer is incorrect when it comes to projects. It's correct for solution files, but they're not actually as important as the project files (as they don't change as often, in my experience, and there are fewer of them).
For example, you might want to look at Noda Time. We have two solution files (NodaTime VS2008.sln and NodaTime VS2010.sln) which load the same project files. This provides a pretty practical solution to having developers working with different versions of Visual Studio.
Manually change the first part of the project file to look like this:
<Project ToolsVersion="4.0" DefaultTargets="Build"
xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
(Basically just change ToolsVersion to 4.0.)
You can also just let VS2010 convert the projects automatically and compare them afterwards if you want - see whether it's done anything else that you don't want.
At that point, when you build in VS2008 you'll get output such as this:
Project file contains ToolsVersion="4.0", which is not supported by this version of MSBuild. Treating the project as if it had ToolsVersion="3.5".
... but it will still work, in my experience. There may be some oddities if you use a lot of designers etc, but generally it seems to work pretty well.
A late answer, but for others in this boat, here's an option if you don't mind conquering a learning curve. Download a copy of TortoiseHg and install it. This is a version control system. (There are other version control systems such as git which can also do this, but they must support patch queues, and TeamViewer does not; however, this isolated usage does not conflict with TeamViewer for source management). Mercurial includes an extension called MQ, and you should enable it. Modify the setup to make Patch Queue Patches secret. ([mq]secret=true, or under settings, Commit, set Secret MQ Patches to True. If you start using Mercurial for change management and do not make patches secret you will suffer great pain as unavoidable accidents occur as the patches are committed to the repository and must be painfully, manually removed from each users copy, only to creep back in via the one user that was on vacation that day.)
Next, create a repository in the solution folder. Look online for an .hgignore file so you don't grab a bunch of crap, but if this is your only goal, you can ignore everything but the *.sln and *.*proj files. Place all of the files in there under the oldest version of Visual Studio you use. Next, open the solution file and allow Visual Studio to perform an automatic upgrade. Then open the TortoisHg workbench and create a new patch that contains all of these changes.
From here on out, you can make whatever changes you like to the source, and place them in another patch. When you're ready to share, open up the workbench, pop off all of the patches, and drag the upgrade patch to the top, and pop all the patches back on except for the upgrade patch. Finish (Repository->change history->finish patch) all of the patches (except for the upgrade patch). Your changes are now incorporated into a version of the solution that is based on the oldest version of visual studio that you have in use.
When you obtain updates from other users, pop your upgrade patch off, apply the changes via a changeset or shared patch, then pop your upgrade patch back on last. Repeat as necessary.
This does not capture modifications to the projects or solution file, since you will pop those back off when you remove the upgrade patch, but 99.9% of all source code is completely backwards compatible. So other than adding new/existing items to a project or adding new projects to a solution, this should cover the majority of your work. For changes to projects, perform those on the oldest supported version of visual studio, delete your upgrade patches, and recreate a new upgrade patch.
This is kind of a usability question for using VS2005: I have different branches of the same Visual Studio 2005 solution checked out from version control. The solution and project files are also under version control. On my development workstation, I sometimes have multiple instances of Visual Studio opened on a different version or branch each. They all show up under the same name in the window title and the taskbar, which makes it hard to switch to the correct one etc. (The same goes for the list of recently opened projects in the startup page, but I rarely use that, anyway.)
I tried to find a way to only change the name displayed while not running into too much trouble with source control, but Visual Studio 2005 seems to take the solution name from the name of the SLN file itself, not from some attribute inside of it.
It would already help to have Visual Studio show the full path to the solution file in the title bar, but I haven't found a way to do that, either.
How do you handle different versions from the same solution?
Use the (free) VSCommands plugin:
http://geekswithblogs.net/deadlydog/archive/2011/04/29/friendly-visual-studio-solution-names-for-branches.aspx
I guess it only works when using different folders for different branches (not SVN switching), but still, it's good stuff.
Same issue here. VS has bad support for equally named solutions in different directories.
A somewhat hacky workaround: http://www.helixoft.com/blog/archives/32
There's an ideal extension for your problem, but you must use at least VS 2010:
http://visualstudiogallery.msdn.microsoft.com/f3f23845-5b1e-4811-882f-60b7181fa6d6
It changes the title bar, so must not rename solutions or files.
I know that is an old post, but perhaps you have now a newer VS version :-)
Why don't you rename the solution file on your branches, e.g. MySolution-branchXY.sln?
Update:
I'm not sure I understand your comment.
As soon as you have branched your solution, you have two independent versions of each file: one on the trunk (or source branch) and one on the new branch. The two files simply share a common history, but you are free to change them independently on both branches. So you can rename the solution in your branch.
I'm trying to use Visual Studio 2005 with ClearCase eclipsed files (view private which "eclipse" a versioned file), but any time I save the file in VS, it becomes uneclipsed, and returns to the versioned file. In Linux, I use VIM instead of Visual Studio, and get around this problem by setting backupcopy=yes, thereby forcing it to save files by writing to a new file and then copying the new file over the existing one, instead of moving the original file out of the way (which undoes the eclipse) and then writing a new file, but in Windows, I'd like to use Visual Studio (since the tree also includes C# code compiled under VS). Is there any way to teach it to save files this way?
I do not think Visual Studio does save file in a particular way that may cause the file to be first removed, then written.
Considering that, with developer's environment as Windows with Visual Studio, eclipsed
files often happen just by writing a file case sensitive and later not case sensitive.
Hence, did you check the case of your file ?
Could you also check the config spec associated with your Windows view ? (and compare it to your Linux view).
I just spend 1/2h with a Visual Studio 2005 / ClearCase / dynamic view and... I do see the same thing!
The only workaround I can fathom is to add a non-selection rule:
element /my/private/file -none
That way, even though VS2005 remove then add the private file when saving it, ClearCase does not try to restore the versionned file, since it is not selected at all.
Si, the answer may not reside within VS2005 (I studied the options without seeing any obvious setting altering the saving process...), but rather within ClearCase.
Let me know if it helps.
As noted in the comment, the downside of this approach is "un-eclipse" can no longer be a matter of moving/removing the private file to let ClearCase dynamically restore the versionned file.
Now, that step must be complemented with another one, which is to comment the non-selection rule in the config spec.
If anyone is still reading this... I just discovered that Visual Studio 2008 appears to work just fine. Go figure...