I have a project in visual studio (c#) which is using .net 4.5, I arrived at a point where I need to debug the framework source to understand what's happening in a multithread deadlock.
I found http://referencesource.microsoft.com/netframework.aspx, where you can download the debug symbols, and I saw that there is a .net 4.5 update 1. Ok so I search on microsoft.com the update, install it, restart the pc, then install said debug symbols and configure visual studio for using them.
Problem: when I debug my project and try loading the symbols (like mscorlib), visual studio says that there are no matching symbols in the folder.
I saw this: How do you enable "Enable .NET Framework source stepping"?, in which it is said to disinstall the windows updates, but I have only installed KB2707250 (VS2012 update 1), KB2504637 (alters System.Net assembly), and KB2750149 (the .net 4.5 update 1) -- there are not other updates.
So the assemblies reported versions are v4.0.30319.18033 and v4.0.30319.17929, which from what I understand are v4.5 and v4.5 update 1 where it applies.
Fact is, I downloaded from referencesource.microsoft.com both debug symbols for .net 4.5 and .net 4.5 update 1, which, considering there are not any relevant updates on my system, should correspond to the installed frameworks.
But evidently it's so only for 5 of 18 referenced assemblies (project excluded).
How can I gather additional informations?
How can I make visual studio and the debug symbols work happily together?
In the end I can see the source, that's not complicated, but I don't know what values there are in fields and properties...
UPDATE:
I've been able to obtain the correct pdb ({3303BFEA-79E7-40C2-A2A8-34C1C816E082}), but still it lacks the source, so it's useless. Srctool doesn't seem to be useful either in this case.
Now the funny thing is: I have the source, AND I have the pdb, but it doesn't seem they can be used together. Don't know, maybe I'll think about recompiling mscorlib, if it's possible.
->No, apparently the answer is no.
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.
When I try to register a visual studio package using regpkg in Visual Studio 11 RC, I get the following error:
regpkg.exe /root:Software\Microsoft\VisualStudio\11.0 /codebase myvspackage.dll
Could not load file or assembly 'Microsoft.VisualStudio.Shell, Version=2.0.0.0,
Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The
system cannot find the file specified.
This worked fine with previous versions of Visual Studio. I'm working in a clean virtual machine that only has Visual Studio 2012 RC.
I've been surfing the web looking for a solution with no success.
If I just copy the Microsoft.VisualStudio.Shell.dll in my app location it works fine, but this dll is not redistributable, so... what's the right way of registering a package in Visual Studio 11?
Thanks in advance for your help,
Luis
I'll assume you also posted this to the MSDN forums since a question with identical text was posted there which I answered yesterday.
http://social.msdn.microsoft.com/Forums/en-US/vsx/thread/96556cd4-44dd-4e01-8198-b83a66c6df26
In short it sounds like you have an explicit reference to v2 of Microsoft.VisualStudio.Shell.dll, James is incorrect in saying you aren't supposed to use this, this is simply MPF from 2005. Referencing it is perfectly fine. If you have an explicit version in the reference in the project file try dropping it, if not try adding the binding redirect mentioned in my MSDN forum post.
I have started a mail with the SDK team about this issue though I don't know if they will be taking any changes this close to release. Also, as an FYI, since Shell.dll is from 2005, it is nearing the end of its supported life, we generally support three versions of previous VS releases.
On release of 2012 the support will be 2008,2010, 2012. I suspect in the next release (after 2012) we may stop including Shell.dll (the 2005 version) entirely in the shipped product. Unless you need to run downlevel on say 2005 I would update the reference to one of the newer shell assemblies (like 9.0, 10.0 or 11.0)
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?
When I change the target framework of any project in Visual Studio 2010 it does not actually change the System assembly references. For example if I target v2.0 and check the properties of System and System.Data I can see that they are still both v4.0. If i change the target to v3.5, System stays at v4.0 but System.Core changes to v3.5.
Because of this I am truly not targeting anything except v4.0.
There may be something strange in your install. I just created a WPF project, keeping the default settings, thus targeting .NET 4. Then, I switched to 3.5. VS asked to reload the project and then the targeted runtime of the references was v2 (correct) and their version was 3.5 (with an error that Microsoft.CSharp and System.Xaml were missing, which is understandable).
Then, I did the same for .NET 3 and 2 and got the same results: after reloading the project, the version of the referenced DLLs had changed were it made sense (System.Data is always v2.0).
When using the CLR v2, the vshost debug helper had its name changed to something like vshost-clrv2.
I've reinstalled Visual Studio several times and it hasn't solved anything. After uninstalling there is 10.0 stuff laying all over the place leading me to believe the uninstaller is also leaving what ever is causing this issue. I'm going to have to reinstall the OS to get the issue to go away.
I also wanted to link to my earlier post because this post has more information about how I originally discovered this issue, contains a link to the Microsoft Connect bug report I opened and links to several other users experiencing the same problem: Visual Studio 2010 Can no longer build .NET v3.5
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.