I have a project on SourceSafe that the team work with VS 2005.
I have installed VS2010 and like some features of this version.
Is there a way that I keep the project to day with SourceSafe, but however work locally with VS2010.
Say, I could not add new files to solution, but at least obtain, modify and archive the existing ones.
You can update all of the source files pretty safely unless you're adding code that is new since VS 2005. The main difference between the VS versions is in the project, and the solution files. What you can do is make your local project and solution files writable, and then use your source control to modify the source files. When all is said and done though you'll want to build it in 2005 (with the SourceSafe versions of the project and solution files) to make sure it all still works.
Also note that the conversion utility in Visual Studio that converts projects from previous VS versions is only intended to convert projects from the previous version. Since VS 2010's previous version is VS 2008 and not VS 2005 you may have to perform manual changes on your solution and project settings to get everything to build. The main thing that comes to mind is how global include directories are handled. If you have access to VS 2008 convert it to that first, and then to VS 2010.
Besides targetting the 2.0 framework VS2010 will still let you use new language features so you have to be careful.
And as Ben Burnett said, the sourcesafe binding doens't have to be a problem as long as you don't check out project and solution files. You can remove the read only flag from them so VS2010 can edit them, but they don't need be be checked into sourcesafe.
But I really wonder which feature you like so much about VS2010 that you want to restrict yourself to not be able to add, remove or rename files from your project.
Related
I have a suite of C++ programs in Visual Studio 2012. I want to provide project and solution files for Visual Studio 2013 and 2015 as well (and later versions as they come), in the appropriate subfolders.
Is there a way to get Visual Studio to leave the old project and solution files, while adding the new ones?
No, it will convert the older version to a new one (or at least try to) on the first open attempt. But you can easily achieve the desired effect by manually creating 3 sets of project/solution files, each corresponding to different version.
Note though it's probably not a good idea to have a SW compatible with different compilers/IDEs. There are many differences between different compilers, the changes between VS2013 and VS2015 are especially extensive. Most likely you won't be able to immediately compile without errors on both of them. Some errors you'll be able to fix to satisfy both compilers but there are some changes that aren't backwards compatible, so you'll end up with multiple #ifdefs in the code which is not desirable from design and maintenance aspects. Also, maintaining multiple versions of project/solution files will be a pain in the ass.
Looked through some similar questions, could not find one that fits my case.
I have a solution that I created some time ago in VS 2010 (maybe originally in MVC2), and eventually upgraded to MVC4.
The solution works properly when opened with VS 2010, builds and runs - everything as expected.
To confirm that I use MVC4, I checked the properties of my System.Web.Mvc.dll. It appears to be 4.0.0.0
From this I assume that I have MVC4 successfully installed on the machine.
However, when I try to open the solution with VS 2012 I get the following infamous error
Full text:
Unsupported This version of Visual Studio does not have the following
project types installed or does not support them. You can still open
these projects in the version of Visual Studio in which they were
originally created.
- Recipes, "C:\ ... Copy\Recipes\Recipes.csproj"
I can also create a new MVC4 project using VS 2012, so I'm assuming I don't lack any tools VS 2012 needs.
What else could be the problem?
There's probably an entry in the <ProjectTypeGuids> element of the .csproj file that VS2012 doesn't recognize. I have a vague recollection there was some tooling identifier change but I can't recall specifically.
My suggestion would be to create a new project from scratch and then compare the <ProjectTypeGuids> elements in each .csproj file to try to figure out which one from the VS2010 project it doesn't like in VS2012. It's likely going to require some trial-and-error tweaking of the list so make a backup of the file first so you don't get yourself into a situation where you can't open it at all.
If you don't want to take that approach another option would be to create a new empty project and then import the individual files from the old project into the new, but that could obviously be quite time-consuming if it's a large project.
Sometimes I do consultancy work for companies that are still using Visual Studio 2008, but I have 2010 installed.
I assumed (yes, assumption is the mother, father brother and sister of all f-ups!) that I would be able to open 2008 projects in 2010 without having to upgrade them. However, it appears that this is not the case?
Unfortunately, choosing to compile for .NET 3.5 wont solve this problem as the original developers will need to continue to develop the same projects in 2008
You can't leave a project in VS2008 format and there's no automatic way to downgrade a VS2010 project to a VS2008 project.
There are a number of differences to the files:
<Project ToolsVersion="3.5" ...
becomes:
<Project ToolsVersion="4.0" ...
The <ProductVersion> changes from 9.0.30729 to 8.0.30703 (though I am only using the 2010 Express editions at the moment so this might be different for the full version).
Alternatively you could upgrade the project on your machine and just copy back the source files. However, this would require more work if you added/removed any project files as this would have to be repeated on a machine running VS2008.
Unfortunately, I don't think there is a backward compatibility option for VS2010.
What I have been doing is upgrading the VS2008 project to 2010, and leaving backup copies of the project and solution files. I then rename all of the upgraded files to project_name_vs2010.* and rename the backup files back to the original name, since I'm the only developer using 2010. The downside is that any changes you make to the project or solution need to be redone inside of VS2008 (or manually edit the XML if you don't have a copy of 2008) before you push your changes. The positive is that all source files will work in both versions thanks to VS2010's multi-targeting. You'll definitely need to keep the compiler setting to 3.5 in order to keep all the source files compatible.
I faced this same issue with 2005 to 2008. If you aren't using anything that is not supported in the earlier version, such as .Net 4, then all you need to do is revert changes VS makes to the .proj file to then open it again in 2008. This is very annoying to have to do repeatedly but I think it is basically your only option.
You Can't.
However, you can have multiple solutions (one for 2010, one for 2008) which each reference the projects. The project files themselves don't have to change.
If you go this route, you have to make sure the project targets are no higher than .Net 3.5.
I'd like to give VS2k10 a shot, but I'm in a VS2k8 environment. I compared the upgraded project files in VS2k10 and the only difference was the updated version number - how can I stop VS from doing this?
Probably the only way to open the VS 2008 projects safely in VS 2010 will be to make a copy and open the copy in VS 2010. In my experience, it's impossible to revert back once you have opened a specific project in a later version of VS unless you feel like changing the version number in the project files.
This was true with the 2003 to 2005 switch, and also with the 2005 to 2008 switch.
It also does this for some 2K8 SP1 in some cases IIRC. How about just not checking in csproj files from 2k8 - you never know when you're going to hit a more complex case where you are actually hitting something 2kA specific, and by first making sure everything still works in 2k8 you'll prevent team confusion.
You can't stop VS from trying to upgrade the project. When VS detects that the project file is not high enough for it's version, it will force an upgrade. If you cancel it will then not allow you to open the project.
I find the best approach here is to use two project files; 1 for each version of visual studio. I usually just copy all of the project files, open one and rebuild the solution.
For two of my VS 2005 C++ projects, VS wants to write to the .sln file when I build the projects. I have got a number of other VS 2005 C++ projects where this is not the case. It is a problem as due to the fact that we have ClearCase source control integrated with our VS 2005 installations and when we try and run an overnight build via batch files, the build pauses as a ClearCase check out dialog box is displayed.
Looking at what VS is changing in the .sln files, it is the second GUID on the project line.
Before building:
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "InterCommClientB", "InterCommClientB.vcproj", "{A2AF232A-7F27-4340-81D5-8ABFD10994D2}"
After building:
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "InterCommClientB", "InterCommClientB.vcproj", "{67BE85B7-3234-484E-88FB-4F0E42096583}"
Any help gratefully received. I am new to VS 2005, as we have only recently migrated from VC++ 6.0, so apologies if I have missed something obvious.
We are running VS 2005 Professional Edition, with SP1 installed.
Regards,
Greg.
I had similar problem. It seems that when converting projects from old versions of VS (like 6 or 2003) VS 2010 is not adding Project GUID to the .vcxproj file. Because of that when you open solution including such project VS will recreate GUID for such project, and will change .sln file but will not change .vcxproj file. So another time you open such solution the situation will be the same and the .sln file may change again.
See this: http://connect.microsoft.com/VisualStudio/feedback/details/586258/missing-projectguid-in-vcxproj-files
I am guessing here, but it looks like some changes have been made to the InterCommClientB project(project, not the files in the project). When this happens the sln is updated, in this case only the project GUID.
My best guess to resolve this issue would be to manually build the solution and then checkin the changes. This way the sln file won't change on build.
My second best guess is that you already made this changes at your computer and it is working fine, but you did not get lattest version on the pc where you do the night build .
This might be totally out there - but sometimes Visual Studio fails to check-in a Solution file when it's been modified and while the Solution is open in Visual Studio. Try closing Visual Studio, and only then committing the Solution file.
If it isn't that, there might be some other agency causing the Solution file to need to change the GUIDs its using. In one instance, I was using .NET tools from National Instruments, and they has a licensing scheme that would trigger that sort of action (modification of extraneous files for not good reason) whenever I went to do a rebuild.
Please take a careful look at the output from the build (in the log, or the output window) - you may find some further clues there!