my client using visualstudio 2010 for his application and app OS version is windows 7. they shared the sourcecode of that application and asked me to migrate that code into VSTS. but, i am using visualstudio 2019 with OS version windows 2010 in my system. can we use that sourcecode in my system. any compatabilities are there ?
Yes, but you will most likely have to adjust for the target runtimes/frameworks and configuration differences that the VSProject file will have between the versions. The VSProject file will almost certainly migrated to the latest version for VS2019.
You may not be able to if the target runtime/framework for the application is not supported by VS2019. For example, if it something less than .NET 4.5.2, you may run into problems.
The best solution is for you to get his system, his version of VS and the code base updated to the latest. If this will be a significant effort on your part, tell your client that migration will be a billable item.
If you're merely trying to share code, write, but not build anything you can certainly use VS2019, but at that rate, you may as well us VS Code.
There is no such thing as visual studio 2010 source code. THere is source code, that has been written in VIsual Studio, but a .cs file is a .cs file, regardless of the editor. A text file is a text file. Source code is not like word, where there are a ton of formatting information embedded in a file format that is complex - source code are SIMPLE text files.
2010 to 2019 MAY be a little large for the project file - you have to try it out. That being said, making new project files is trivial.
2010 likely (not sure, it is like ages ago) does not use nuget - you likely run into more problems with .NET versions and links to third party libraries.
Related
Is anyone out there using Visual Studio 2015 and 2017 .CSPROJ files alongside each other in the same folder? Are there any other incompatibilites, besides the solution and project files that I should worry about?
Basically what I want to do is allow our developers to continue to use VS2015 and those projects -- just for a while -- while all still working on exact same set of same code files. I don't want to move/change anything else.
I've already created all the new project files and solution file. But 'm wondering if I can just put them in the same physical disk folder alongside each other and have everyone go merrily about their development tasks with either VS2015 or VS2017.
The duplication of work synchronizing the project files themselves is not a concern. I just want to make sure there aren't any OTHER format differences that might cause some sort of build/run problem for me.
Is anyone else out out there doing this? Is this workable?
There is not any incompatibility, but you should check when you are creating a new project in VS2017 the kind of project, you should have two things in mind, first, when you are creating .net projects, you have to keep using the old .net framework instead of .net core, and second (only if you are going to create desktop/libraries/console projects), you need to use the Common option instead the new option (check on the dropdown to select the .net framework version that allows you to select versions lower than 4.5), cause if not, then you have the incorrect kind of project selected and this kind of project doesn't work in VS2015 as they change the structure of the .csproj file. Hope this little explanation helps you.
Update
What I wanted to say with this explanation is that every projects that comes from VS2015 or 2017 if they have the same structure (same old kind of .net framework), then you can do what you want to do, but if for some reason you need to make a .net core, then this will not work.
Cheers.
Just be aware that VS2017 supports C# language version features that 2015 does not. If anyone uses those features you will not be able to build the projects in VS 2015.
You can enforce language version in the .csproj files but this is done per BuildConfiguration and can be tedious to configure for larger solutions with many projects.
To make the changes
Right click the Project and select Properties
Then Build Then
Advanced (Bottom Right corner) General > Language Version
Change to C#6.0
Overall it is possible but you may need to retain VS2015 if you have any SSIS or SSRS packages as the tooling is still not available for general release (Oct 17) and is still in preview.
You should be able to run Visual Studio 2015 and Visual Studio 2017 side by side without any issues. Our application ran on both Visual Studio 2015 and Visual Studio 2017 before every developer migrated to VS 2017.
You do need to keep in mind few things though:
Visual Studio 2017 by supports C# 7.0. Make sure that you use same language version in both the IDEs.
VS 2017 also supports stuff like editor.config. I would suggest to avoid using it (though I feel it should not be an issue)
If you are using on .NET Core project without csproj. Do not think you would be able to upgrade it.
Every where I look Quick Info in Visual C# looks something like this:
Yet my Quick Info box only shows the name/declaration, without any description.
Are longer descriptions cut from the C# Express version? Or am I doing something wrong? XML comments I'm making work as intended, if it helps.
It depends on the specific framework target and type you selected. But for a 4.5 desktop app, this information comes from an .xml file, C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.5\mscorlib.xml. The relevant part of that file is:
<member name="T:System.DateTime">
<summary>Represents an instant in time, typically expressed as a date and time of day. </summary>
<filterpriority>1</filterpriority>
</member>
So check if that file is there.
Thank you alex and thank you Hans. Both of your answers lead me to my solution. Also thank you for as quickly answering as you did.
The Road to Solution (might be useful for some, if not skip to The Solution).
The file Hans mentioned did exist. Also it did for version 4.0. I also tried to install documentation for Visual Express (as per alex's tip) only to find out that Visual Express 2012 installer doesn't have any options during installation (at least not that kind).
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework also contained v3.5 folder, but there was only a Profile folder and no mscorlib.xml (or other files that v4.5 and v4.0 had).
Realization came when I found out that Unity3d uses Mono equivalent of .Net 3.5 and in the project setting I found that it was setup for .Net 3.5 (if any one is wondering - Visual Studio is used only for coding, Unity compiles everything).
Few hours of searching later I did find the "documentation" for .Net 3.5.
The Solution
What is needed is Microsoft Windows SDK for Windows 7 and .NET Framework 3.5 SP1. The only thing required to check during installation is Developer Tool->Windows Development Tools->.NET Development Tools. All the Quick Infos for C# functions in my project are now showing correctly!
A note: I tried to find mscorlib.xml for .Net 3.5 afterward but no luck, so I don't know where or in what format the XML documentation for .Net 3.5 is kept but I'm happy as long as it works.
More likely, the documentation is cut from the express version to reduce the download size. Have you installed documentation with the visual C#?
I'm developing an open source C# application. For awhile now, I've been using a basic .NET installer I coded myself. However, with a recent change, that is no longer practical for me, as I'd have to add a large number of files to the installer - and they may change with each release. A ZIP file is also not practical.
I've done some checking online, I see a lot of MSI, ClickOnce, Self-extracting ZIPs, and (imo the most promising) the NSIS system. None of them seem to exactly fit my needs, so I'm looking for advice on which system to use.
Actual installing of my program is very simple. Basically, I just need to copy the bin\Release directory (and all subdirs) to the client's computer. I've been achieving this somewhat ad-hoc, by embedding every file in my .NET installer, and maintaining a file table of what goes where.
Unfortunately, I just localized my app. I now have 30+ .resx files (Which are compiled to dlls and placed into MORE subdirectories by Visual Studio) and, obviously, it's impractical to add 30+ folders and DLLs to my installer. Hence why I'm on this search.
There's also a few other requirements:
The installer should search predefined directories for a specified .exe. (My app is designed to be a drop in replacement) If the .exe is not found, it should prompt for its location
The installer should verify that "OldApp.exe.bak" exists. If not, it should rename "OldApp.exe" to "OldApp.exe.bak"
The installer should update files. Ie, if "Culture.de.dll" hasn't changed, the installer will leave it alone.
The installer should work with all Windows versions of all .NET IDEs (VS, SharpDevelop, Mono, ect) but does not need to work on other platforms.
When I build the solution, the installer should be automatically regenerated. In other words, it should be run-able for by "Post-build" section.
The installer generation must be able to be added to a source code repo. This is so that anyone who downloads the source of my app can compile the installer as well.
Sorry for the long post, I figured it was better to post more than less.
I'd recommend SharpSetup. It combines WiX and C# for a pretty flexible implementation. Not much I've found it can't accomplish.
We use WIX extensively: http://wix.codeplex.com/
You may have to customize your installers with some exit routines to do things out of the ordinary, but there are hooks in Windows Installer framework that let you do that.
You can put these definition files (XML) in your source control, and you can configure a build to execute the installation. However, anyone that gets your source would need to have the WIX utilities installed.
I would recommend NSIS. From my experience any installer feature that I have required has been covered in NSIS documentation or community examples. I can't comment on NSIS integration with Visual Studio as I use NSIS integrated with my Jenkins build server. There appears to be a free Visual Studio Add-In called Visual & Installer which provides NSIS integration with Visual Studio. I have not personally used it but it appears to be currently actively developed so might be worth checking out.
WIX is a good one. According to Wikipedia, it is used by Microsoft to produce installers for some of their own products.
So on my computer I only have Visual Studio 2010 Express. I need to edit a Visual Studio 2008 project, however it needs to be kept in C# 3.5.
Before I open it in 2010 and accidentally upgrade it, will it be kept in 2008 or C#3.5 format?
I realize I wont be able to use .Net 2010 features, so thats no problem. I just want to make sure if I save my 2008 project using 2010 I will still be able to open it in 2008 and it will work fine.
The target framework of the project is independent of the solution format. That is, you can convert your project to Visual Studio 2010 and still target the 3.5 Framework. But, once it's converted to 2010, you will not be able to open it in 2008.
You cannot open a project in VS2010 without it being upgraded. The Framework version can be controlled independently, so you can still target 3.5.
The changes to the project/solution files to use 2010 (assuming you don't use any newer features) are fairly minimal, so there may be mileage in just not committing the project/solution files (you can probably achieve this by dropping an ignore file for your source control provider in your local folder, including adding the ignore file to itself, so that doesn't get committed).
If you're mostly editing code (and not often changing the projects in the solution, or files in the projects) you could also have two copies of the files, one for each version, until you can commit to 2010 everywhere (and with Express for free, you might be able to do this quickly?).
No, VS2010 will convert the VS2008 project file. After it is converted, VS2008 can no longer open it. There are ways to hack around this, the simple solution is to just use VS2010 consistently. Next best thing is to only check-in the source code changes. Next best thing is to give the 2010 project a different name and maintain them both, at least for now.
You'd be hard pressed to accidentally upgrade it. When you open a VS2008 project in VS2010, it automatically starts the upgrade wizard, and you have to decide whether to let it do the upgrade, including making a decision whether to let it take a backup before it does the upgrade.
You can't open a VS2008 project in VS2010 and work on it without upgrading it to VS2010 format first. And once you've allowed VS2010 to upgrade it, you won't be able to open it in VS2008 any more.
Careful though - don't confuse the version of the framework you want to target, with the version of VS that you're using.
You can target framework 3.5 with VS2010.
There are hacks that let you open VS2010-upgraded projects in VS2008, but it's not a great plan to go down that road (guess how I know).
When you are going to convert it with compatible to 2010 it will ask for the backup...
so... later you can retrieve your file back ...
I might be wrong but I'm almost sure that project files don't differ between 2008 and 2010 or at least they are compatible. Solution files are a different matter and old solutions do indeed need to be converted. Usually you have few solutions for 2008 and 2010 versions of VS, but they contain the same projects, so the projects don't need to be converted.
I was on a seminar where they took this (short of classic?) accident as a sample for versioning. They get a 2008 project from git and start it in vs 2010.
Did the upgrade process and then "ops, i can't revert the upgrade". They commited the vs2010 converted files to a branch in GIT. When they "came home again", merged the changes in project together with 2008 solution files.
This may not come in touch to you, but the sense is:
All files is intact but the solution/project files. So just keep them safe and you can continue use the 2008 version after done your editing in 2010.
Though, without any kind of manual handling of solution/project files - answer (on the question in your subject) is No!
In short, no. Once it's upgraded, it stays that way. There is no official way to downgrade it either. The main driver behind this fact is because of the compiler. Even if you stay in .NET Framework 3.5, you can still use C# 4.0 features (like optional / named parameters) since 2010 will always use the 4.0 compiler.
Imagine a situation where it stayed in a 2008 format but you used a C# 4.0 language feature. Since VS 2008 always uses the C# 3.0 compiler, whenever you open it in 2008, it will no longer compile. This is a good reason to avoid work-arounds that have been posted for downgrading - you get mixed compiler features that can break things pretty easily.
We have a team on vs 2005. We want to upgrade to vs 2008 but want to do it incrementally. If we have a few folks on the team upgrade to 2008 (still targetting the 2.0 framework) while others working on the same solutions stay on vs 2005, would this cause any issues .
Do solution or project files change due to this?
Are there any backward compatibility issues to deal with or other conflicts that is going to force a big bang upgrade for the team?
Why do you want to upgrade incrementatlly? You can still target .NET 2.0 while working with Visual Studio 2008.
Won't work. 2k8 upgrades your solutions.
Let me qualify that. Solutions, once upgraded, can't be opened in 2005. I believe individual projects can be.
So, one solution might be to make a copy of the solution, call it project.2005.sln, then upgrade the original solution and call it project.2008.sln.
I don't have 2k5 on my box, so I can't test this. It would be simple and, as long as you check in fully beforehand, non-destructive to test this.
You could achieve this by renaming all of the solution/project files (leaving the actual source alone) - then members of your team can load the version appropriate to them.
For C#, the project files are almost identical (different version number, new target platform property). VS2008 however will always try to "convert" the old VS2005 files, while VS2005 refuses to open the new files. Therefore, a mixed environment is not very practical.
What we do with mixed VS versions is create the solution in 2005, with all the project's set up. Then check that into SourceSafe (or whatever you use). Then the users with VS2008 upgrades the solution locally on his machine, then undoes the check-out VS2008 does when it upgrades the solution and everyone can then work on that project at the same time, as long as no changes are made to the solution file!
As far as I know it is the solution file (*.sln) that is changed when upgrading to VS 2008, not the project files .csproj/.vbproj.
So you can use both IDE's for the same gode if you have different .sln files.
We've been doing exactly what you want to do for about 6 months now.
Our experience has been limited to Web Application, Class Library and basic WinForms projects. But we've had no issues with developers split between 2005 and 2008.
You will need two seperate solution files (one for 2005 and one for 2008) but they differ only in that one contains the string "9.0" and the other "10.0".
The project files will be modified by 2008, however it basically only adds new attributes which are ignored by 2005.
2008 Project files ARE compatible with 2005, in my experience.
2008 Solution files are not, but creating a compatible copy is a simple task of replacing the "9.0" with "10.0" or vice versa.
If you are dealing with Web Application projects, there is one additional change you should make to the project file so it is compatible with both version.
See my answers here and here for details.
go for the big bang, 2008 rocks compared to 2005. I have no problems found whatsoever with converting projects.
Partly possible but must be carefull.
Need a version control system (and build server with 2005/2008 based config)
Separate solution and project files based on VS.NET version. Everybody should open just corresponding .sln van .proj files. (Some hints about project file changes: .NET 2.0 Project in VS.NET 2005 != .NET 2.0 Project in VS.NET 2008)
It's possible to commit common C#/VB.NET source files, XML files. Other files - lets say .resx - can causes pain.
I think it's more easier to switch all projects to VS.NET 2008.
One note to VS.NET 2088: we have strange experiences with WinForms designer and had some after-build freezing.