I'm currently using a .net core visual studio publish, and its including the runtime dlls in the output. I do not want these files, but would like to use the hosting bundles on the server.
This is a new thing, it didn't use to include these dlls with a publish. I think it might have been triggered by a visual studio update, but I am not positive why its happening.
Here's my settings:
The Deployment Mode is not set to "Self-Contained" which I think is the setting that should force the runtime to be included.
I've done tons of googling but can't seem to find any other configuration that would be related to this. Any guidance would be greatly appreciated!
Posting an answer, just in case anyone else ends up here. I found the answer mostly because of Lex Li comment.
The most recent upgrade to visual studio / .net core seems to require you to specificity a target runtime in your Publish Profile. In order to make this work, you will be forced to upgrade your project to 2.1 or higher. Otherwise visual studio will choose portable by default, and include the runtime dlls in the publish.
Related
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.
Where can I find some official note, kb article or other documentation describing changes to the Visual Studio 2010 C/C++ runtime linking and deployment policy?
Under Visual Studio 2008 (with the VC90 runtime) a manifest was embedded in native images, and the runtime libraries were deployed as side-by-side assemblies (WinSxS). This caused problems when rebuilding a native exe or library using VS 2008 SP1, in that an updated version of the C++ runtime was required by the embedded manifest.
For VS 2010 and the MSVCR100 runtime version, the policy seems to have changed completely.
The file msvcr100.dll and the other C/C++ runtime libraries are no longer install as SxS assemblies.
When compiling under VS2010, no runtime 'dependency' entry is added to the embedded manifest, meaning that any version of msvcr100.dll might be loaded at runtime.
On machines with .NET 4 installed, the matching runtime is named msvcr100_clr0400.dll, and won't be loaded by native code, though a copy renamed to msvcr100.dll works fine. I think this means any process with C/C++ code will always have two versions of the same C/C++ runtime loaded.
This seems to be a significant change in policy, backtracking from the SxS deployment and manifest dependencies we had under VS 2008. Could anyone shed more light on what changed, and perhaps point to some documentation, a readme or blog post that describes these changes, the motivation and related impact?
It think it's better this way - the strong version manifest and SxS deployment was a nightmare - but I'm surprised at these unexpected and seemingly undocumented changes in VS 2010.
Bonus question: How can I compile my C++/CLI library under VS 2010 to link to msvcr100_clr0400.dll instead of msvcr100.dll? This idea is that the C++/CLI assembly should run with no dependencies other than that installed by .NET 4 (without static linking).
You already answered most of your question, the side-by-side deployment of the CRT was a nightmare that got way too many programmers in trouble. Microsoft agreed and gave up on it for the VS2010 release. It's back to a DLL in c:\windows\system32, named msvcr100.dll. And msvcp100.dll, vcomp100.dll, atl100.dll, mfc100.dll, mfcm100.dll, the other runtime support DLLs. The way it was for VS2003 and earlier editions. Now it is again the user's burden to sort out a DLL Hell problem. The person least likely to be able to do so but they do tend to have a budget to pay for support. Unlike programmers that need to get help from a free web site :)
But you can help, app-local deployment is now again enabled, you can deploy msvcr100.dll in the same directory as your main EXE. That was explicitly checked and forbidden in previous versions. App-local has some niceties, it isolates you from well-meant but unfortunate updates that break your app. Albeit that you are now yourself responsible for getting updates deployed that fix a security hole. If that's uncomfortable then deploy and rely on the copy in the system directory.
Do not try to link to msvr100_clr0400.dll, that's a private copy for use by the CLR. Much like msvcr.dll is a private copy for use by Microsoft DLLs. You don't have the .lib file you need to link to these DLLs.
Just a couple of links about the topic – I hope someone will find them useful:
Visual Studio 2010 changes for VC++ (part 5)
Visual C++ Application: How to use manifests and re-distributable assemblies?
I have installed VS 2010 and want to migrate all code written in VS 2005 to VS 2010.
Please note that we do not have VS 2008, all code are in C# 2.0 and Asp.net 2.0 only.
Can anyone please tell me now what all points need to be considered while migrating.
Update:
I have set target framework to 2.0 for all of my Libraries and web projects. It complies without any error!
However, when site opens in IE (Set to default.aspx), it gives me error as below:
InternalXmlHelper.vb(9) : error BC30560: 'ExtensionAttribute' is
ambiguous in the namespace 'System.Runtime.CompilerServices'.
<Global.System.Runtime.CompilerServices.ExtensionAttribute()> _
Keep all the target framework settings to .NET 2.0. This way, there should be no compilation problem at all.
The changes that you should see are the solution and project files only.
Start with known good solutions in source control (and label—you shouldn't need to go back, but easy to add an extra safety net).
Open each solution in VS2010, allow the conversion wizard to do the conversion.
Resolve any issues.
Honestly, if you're just upgrading VS 2010 you don't really need to consider much. Just keep backups (any real SCM product will do) and you're good. You don't have to upgrade your applications' runtime targets at all if you don't want to.
If you're building with CAS policy, you might run into issues with using MSBuild 4.0 to build you 2.0 applications. If you don't know what I'm talking about, never mind.
My advice is to make sure everyone's "checked in" to your source code provider, and run the conversion wizard and see how it goes.
We're planning on updating our developers from Visual Studio 2005 to 2008. Are there any common "gotchas" to look out for during this move?
My major concern at the moment is that we use WSE 3.0 quite a bit (mostly to consume external .asmx web services, but we also host a few ourselves). Will that be an issue since WSE 3.0 has been replaced by WCF?
Additional background info: VB.NET application with several web sites, not web applications. Currently using .NET 2.0 with plans to upgrade to 3.5 soon as well.
Anything else we should be concerned about?
I think the main issue you have to watch out for is upgrading teams. Once you upgrade to a new version of Visual Studio, you will be forced to upgrade your project files as well. Once the upgrade is complete the file will no longer be compatible with previous versions of Visual Studio. This means that you will break anyone who is using the previous version of VS to develop. The best advise is to upgrade the entire team.
The best way to work around this is to keep 2 versions of the project file around. One for the previous version of Visual Studio and the other for the current. This obviously has a bit of overhead. And Once you actually start using new language features this will no longer be a sufficient as the new features likely won't compile in the old versions of Visual Studio.
The changes in the visual editor for things like ASP.NET projects (especially when it comes to styling elements) is very different and can be incredibly frustrating at first.
I've found VS05-08 migration pretty painless. In theory, you should be able to simply open the 2005 solution in VS2008, let it convert, and everything just works. VS2008 lets you 'target' a specific version of .NET, and the default here would be that it continues to target .NET 2.0. That said, 3.5 is an additive update, so there should be little or no breaking changes to any .NET 2.0 code should you change to 3.5 (which is just a drop-down-box to change). I'm pretty sure the WSE stuff should "just work".
In practice, things like project templates, dependencies, etc. could be an issue. Web sites and web applications are still both supported, so I think that shouldn't be an issue either.
In the end, just make a backup of everything, then open in VS2008 and see what happens.
Is there a way to download older versions of Visual C++ Express? I'm particularly interested in Visual C++ 2005 Express (PRIOR SP1) and Visual C++ Toolkit 2003. I tried googling for them, but all the sites linked to microsoft.com, from where microsoft (for some reason) has taken them down.
If you want to link your application against the RTM (pre-SP1) version of the CRT (C runtime), you can apparently do that by defining _USE_RTM_VERSION in your project or on the compiler command line.
Also, deploying the CRT as a private assembly should still work with the SP1 version of the CRT. If that is what you have tried to do, posting more information about what went wrong might help you find a solution.
I also put this in a comment above, but just to make sure you don't miss it: if you're trying to do this because you're having problems with deployment and different versions of dll's, have a look at App does not run with VS 2008 SP1 DLLs, previous version works with RTM versions.
For those of us who find this answer looking for something after 2010 the following link worked as of this posting:
Older Visual Studio Downloads
Microsoft owns it. If they don't have a link anymore, I think you're out of luck.
I'll bet their web crawlers automatically page their lawyers if they ever find a copy on the web.
There is no good reason to run 2005 before SP1, you do realize 2005 /w SP1 compiled code will run the same for the end user, they don't need to install a .NET SP to run the code.
The SP fixes bugs, security holes and various improvements, virtually no functionality changes, you only loose by not using /w the latest SP.
From my personal experience the software compiled with SP1 doesn't simply work, if the end user hasn't installed the redistributables. Without SP1 however it is possible to get the .exe working if you distribute it with the required .dlls.