As the title!
Can visual-studio-2013 RC open projects created by visual-studio-2013 standard edition?
I have created projects by visual-studio-2013 standard edition.
Then someone still used the RC.
Is there any troubles?
In general IDEs are backwardly compatible in that they can open projects created by (at least the last few) older versions of themselves. They have no knowledge of newer versions though so you are always taking a risk when you try and open a newer project with older software.
Related
I am not sure if that is something generic or our project specific issue. we have mvc application and I recognized the other day that every time I open the solution VS 2015 update 2 checking out the solution. when I compare the difference /change, I see that it is the Visual Studio Version as below in the screenshot.
This is because my colleague had lower version number. But I wonder why VS checks out the solution when the version numbers are different? It doesn't even happen when I open the same project with VS 2013.
TFS version is 2012 running on TFSVC.
When you open the solution using a another version, it will update the version accordingly. This would be to ensure that if functionality were not backward compatible, other users would get a warning if the tried to open using an older version.
This also happens with database projects when you update SSDT.
As you are running the same major version, it should not be an issue even if you checked in the change.
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 need to deploy some Crystal Reports XI .dlls (craxdrt.dll, crviewer.dll) to client computers. Craxdrt.dll has many dependencies. I found out that the easiest way to go about this is to use the supplied merge modules. Having always relied on ClikOnce deployment I am at a total loss how to do this.
If it matters: the .exe is written in VB6, but I have visual studio 2010 to make setup projects.
Thanks!
Ideally you'd use the Visual Studio Installer 1.1 that Microsoft supplied as an add-on to VB/VS 6.0 a long time ago. While a bit long in the tooth (and recently removed from Microsoft Downloads) it works fine and was intended for just this purpose. The process is described in the Help that came with the product.
However if you have an edition of VS 2010 that can create real Setup projects (i.e. not Express) it should work in a very similar manner. It should be a standard option to add MSMs to a Setup project.
See http://msdn.microsoft.com/en-us/library/aw2dz878.aspx
I'm asking this specifically regarding Visual Studio 2008 and also the upcoming Visual Studio 2010.
If we are given a project that has been created in an edition of Visual Studio such as Team Suite or Ultimate, and all we have to work with is Professional, would that interfere with us working with the project? I'm assuming the code would all work as it just uses the Framework, but what about features specific to the higher versions? Any IDE issues?
Edit : Our specific scenario is that we're working with a large software company that uses the top versions, and we don't. There's a significant (and growing) amount of code exchange. Given that Professional 2010 with MSDN is $1200, and Ultimate is about 10 times that, we'll have major budget issues if the whole team needs to upgrade. Knowing that the projects will compile is fine, but I'd want to be sure that we couldn't find aspects of their solutions that we weren't actually able to work on.
Nope, there are no issues with moving from Team System / Team Suite to Professional. I have a Professional license at home and a Team System license at work - they interchange and work perfectly with each other.
First hand experience shows no issues.
This is, of course, assuming that you aren't using any of the Team System specific features such as the Team Foundation Server or the Testing capabilities of Team System.
There shouldn't be any issues with opening projects created in different editions of the same version of Visual Studio.
I haven't tried between Professional and Team Suite for example, but there are no issues with opening projects that created in the Express edition in the Professional edition and vice versa.
There may will be aspects of the project you can't access/use any more, but the project should still recompile and run. To clarify this a bit more, in the case of the Express versions plugins (such as ReSharper) won't be run, so if there's any aspect of the project that relies on plugins it won't work). I think with Team Suite or Ultimate going to Professional you should be OK.
You will not be able to use features from the more expensive versions but there are no problems working with everything else.
I have a solution here that contains project types I can't use but I can compile and run everything else.
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.