When I converted a VS 2005 project to VS 2010, with all projects still pointing to compile for the .NET 2.0 Framework, the dlls generated are a totally different file size. Is this normal or something to be concerned about?
The difference in file size is probably due to changes in the compiler shipped with the new version of Visual Studio. In theory, it should be more efficient. It should not be anything to worry about, but that doesn't mean you should forgo testing.
Microsoft does publish information on "Breaking Changes" with the new version of Visual Studio, e.g., http://msdn.microsoft.com/en-us/library/cc714070.aspx for VB, http://msdn.microsoft.com/en-us/library/bb531344.aspx for C++, and http://msdn.microsoft.com/en-us/library/ee855831.aspx for C#.
Related
I have a Visual Studio 2013 solution, and I would like to make it work with Visual Studio 2005. How can I downgrade the solution file?
I noted this line in the .sln file:
MinimumVisualStudioVersion = 10.0.40219.1
However, changing this line to 8.x.xxxxx.x, lower than my Visual Studio version number, still failed with the same error.
Open the .sln and project files with a text editor, Notepad will do fine. The .sln file is the easier nut to crack, it has not changed much over the years. You'll see something like this at the top of the file:
Microsoft Visual Studio Solution File, Format Version 12.00
# Visual Studio 2013
VisualStudioVersion = 12.0.21005.1
MinimumVisualStudioVersion = 10.0.40219.1
Followed by a list of the projects and the configurations. The "Format Version" is the most important value, if it is a mismatch with the VS version then it will quickly fail to load the solution. Values are 8.00 = VS2005, 9.00 = VS2008, 10.00 = VS2010, 11.00 = VS2012, 12.00 = VS2013
The lines that mention the VS versions were late additions, first added in VS2012 to support the feature where VS can open old projects without having to upgrade them. Just delete these lines.
Then you'll have to tackle the project files, they are certainly the harder nut to crack. You did not mention the language you are using, it does matter rather a lot.
First off, if this is a C, C++ or C++/CLI project (high likelihood given the request) then stop right now. Versions of Visual Studio prior to VS2010 used a non-standard build system for those languages, driven by the VCBuild.exe build tool. The .vcproj file format was very different and does not resemble the later .vcxproj file format at all. Only re-creating the .vcproj file from scratch is a sane approach.
If it is a .csproj or .vbproj file then you'll have a shot at it. The best way to go about it is to start a new project in VS2005 so the core entries in the file (Project, Import and PropertyGroup items) have a reasonable value. Then copy/paste the ItemGroups from the VS2013 project file. You'll get the correct reference assemblies and source files that way.
As Visual studio doesnt support for downgrade, you can't do it directly or by changing any file, I suggest better way to do is create another project in visual studio 2005 and import all files in it.
You can do this only if you didn't used any higher version libraries in your project than VS2005
Simple answer is that you can't (as far as I am aware). Fastest option would be to create a bank VS2005 solution and project to mimic your existing 2013 version. Then cut / paste the file listing between the two projects until it opens and builds in 2005. You also won't be able to use any functionality greater than .NET 2.0 and/or NuGet, which wasn't around / supported at that time.
VS2013 would have to convert a VS2005 solution / project just to open it, so there isn't really any hope of it going backwards (i.e. VS2005 being happy with a VS2013 solution/project file)
Visual studio project converter does the work for you. We are using it with success for VS2012 => VS2008 downgrades.
But if you have time, I would recommend you to inspect the code of this project and make a custom script in order to do the transformation. This way you can add it with no friction to your continous integration environment.
I've browsed around StackOverflow but couldn't find any pratical solution to something that would seem to have such an easy solution: I had a bunch of .Net projects that were developed back in VS2005 or VS2008 and I imported them into VS2010. One of them is a C++ project, which currently targets framework 4.0 (not by my choice). One of our clients is having a problem running this application, the lack of a MSVCP100D.dll. I checked this thread what is MSVCP100D.dll? and the most accepted answer is simple: having the client install Microsoft Visual C++ 2010 Redistributable Package. However, the client is stubborn enough not to install it and I know for a fact that they have Microsoft Visual C++ 2008 Redistributable installed. So, if I'm correct in my conclusions and MSVCP100D.dll is new to VS2010, I could just target a previous framework version, rebuild the project in VS2010 and I'd be good to go. The problem is: how do I chance a VC++ target framework? I could find several guidelines to change C# and VB projects, but none about VC++. Any pointers?
Edit: To you guys who suggested that I compile it in Release mode: I am! It's been pointed out that the "D" stands for debug, which is rather strange.
Actually, you are using the debug version of the runtime (That's the "D"). Did you try compiling with a non-debug version?
Another possibility to consider would be to statically link with the runtime library. Your program will be larger, but will not have the DLL dependency.
Go into the project's properties.
On the lefthand side, go into Configuration Properties > General.
Look at the Platform Toolset value. Select v90 from the drop down list to target 2008.
See here for further details:
Visual C++ 2010 compatibility with VC 2008
See here for yet even more details:
http://blogs.msdn.com/b/vcblog/archive/2009/12/08/c-native-multi-targeting.aspx
Also as Dark Falcon mentions, that's the debug version of the runtime.
I just installed trail version of Visual COBOL with visual studio 2010 from Micro Focus. I am trying to compile one of my old COBOL programs into .NET assembly. When I compile, it creates .IDY file exension file in the bin floder. I want to decompile assembly to C# code. Is there anyway I can do this?
Thanks..
[Note: post from Micro Focus]
As the previous poster noted, the IDY file is only used to support the debugger.
If this is a managed code project (and you can create both managed and unmanaged (native) code in VS 2010 with Visual COBOL), then you will the assemblies in standard MSIL just like any other .NET language. Bear in mind this is not code that's intended to be human-readable and depends on the Micro Focus COBOL runtime so you can't reverse engineer the code to some other language such as C# (there may also be license agreement issues).
Try renaming it to *.dll, and load it into Reflector. If that fails, MicroFocus is doing something funky and that's not a .NEt assembly. This is probably not unreasonable. The .IDY file could be some form of pcode, which is interpreted by some runtime (that is real .NET code)
The .idy file contains data for debugging, so using reflector on it will not work just like reflector does not work on .pdb files.
As you all know the VS 2010 RC is out for MSDN subcribers.
Unfortunately I guess I have the same problem as some of you, in that the company I work for wants to continue keeping our projects on VS 2008.
I would like to know if its possible for me to work with VS 21010, then later convert my projects back to VS2008?
I intend to use v3 of the framework for this particular project.
Thanks in advance..
I've just created a little batch file that will convert between VS2008 and VS2010 (and vice versa) at will.
It rewrites the strings found at http://blogs.msdn.com/rextang/archive/2009/07/06/9819189.aspx between both versions in an automated fashion.
It depends on a kind of project you use. It's absolutely impossible to convert VC++ back from 2010 since they have completely different format and no tools to rollback. However, C# and VB.NET still use the same msbuild project format as in VS2008, which will be changed in the next VS version (Dev11) and so all you need to manage C# or VB.NET project version is the ToolsVersion attribute of the Project element.
VS 2008 C# project version:
<Project DefaultTargets="Build" ToolsVersion="3.5" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
VS 2010 C# project version:
<Project DefaultTargets="Build" ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
One of the approaches is to use both project systems simultaneously as our team does. Another one is to use targeting for different .NET frameworks in VS2010 projects. V2010 supports all previous .NET frameworks as targets farmeworks till .NET 2.0
Finally, don't be upset by using VS2008 as it's much faster and reliable.
I think it would be easier to keep the work projects in VS 2k8 and just convert up to VS 2k10 on your end. Of course this means you would have to manually edit back in any changes you make to the solution or project files but you would have to do that either way you go.
Perhaps it would be best if your company invested in utilities (such as SCons or CMake) that are able to generate solution/project files for as many IDE's as you need given a set of metadata so that the companies engineers can use whatever environment they are most comfortable with.
While I think there is an argument to be made for having everyone work in whatever IDE suite they are most comfortable with ultimately productivity will be the deciding factor. If engineer's are spending too much time converting project files back and forth between IDE's, well then having a standardized suite of software is probably the wise choice.
to convert visual studio 2010 solution file (.sln) to visual studio 2008 solution file (.sln) simply follow these steps:
in .sln file replace "Format Version 11.00" to "Format Version 10.00"
in .sln file replace "# Visual Studio 2010" to "# Visual Studio 2008"
in .csproj replace "ToolsVersion=''4.0''" to "ToolsVersion=''3.5''"
in .csproj replace "v10.0" to "v9.0"
I am using the open source Saxon XSLT processor for .NET to execute some 2.0 transforms.
I reference the saxon9api.dll as I would any other dll, and can compile code against this. However Visual Studio does not show any intellisense making the IDE as useful as notepad.
The saxon9api.dll is using the IKVM Java for .NET platform, and I wonder if this is the causing VS a problem. Reflector can inspect the DLL without issue, but I suspect VS is not happy for some reason.
Any ideas?
EDIT:
Surprised that no one else has encountered this behaviour seeing as Microsoft recommends (link is now dead) the use of Saxon in the absense of built in functionality in the framework.
I think I will reword the question to be about assemblies running under IKVM not showing intellisense although I will need to find another IKVM based project to prove that this is the case first...
To make compiling, running and intellisense work in Visual Studio, you need to do the following:
Reference saxon9api.dll, as you already did
Reference IKVM.OpenJDK.Core.dll
Reference IKVM.Runtime.dll (not sure this is needed, but I always include it)
If you are also referencing vjslib, you may run into issues, because it uses a lot of the same namespaces and classnames, leading to ambiguities that can cause Visual Studio's intellisense to get into problems. Perhaps other libraries exist that show the same namespace clashes. In that case, try this on a fresh project first and add the references one by one, starting with Saxon's dependencies first.
After you do this, at least in Visual Studio 2010, 2012 and 2013, you will find that the context-sensitive help is working (image is of VS 2012 with R#):
Note: since this post is old, it may have only applied to Visual Studio 2008 at the time, I have not tested that as I am not using it anyore.