The Black Box of .NET Headline Animator

The Black Box of .NET

Tuesday, February 1, 2011

Referencing platform-specific (x86/x64) assemblies in Visual Studio projects

CodeProjectRecently I've been thinking about how to make Assembly References dependent on the Platform Architecture for a given compiled application/library. A solution for this problem is necessary as you begin to move your apps to the x64 platform.

There are 2 solutions: one method is for "project-references"; the other is for "path-hardcoded dll references". Unfortunately, both involve manually editing the .csproj file yuk... AFAIK, there is no way to do this within the VisualStudio 2008 UI - I don't know about VS 2010. Note that it is NOT necessary to modify any of the references to the .NET dlls.

One quick note about these solutions is that they are independent of the Platform Architecture of the machine that is compiling the projects!

After opening the .csproj file in a text-editor (or as a .xml file within VisualStudio), do either of the following depending on your needs. Note that valid platform values are either: x86, x64, or ia64.

Platform-Specific Project References:

<ProjectReference Include="..\SomeLibrary.csproj" Condition="'$(Platform)' == 'x64'">
    <Project>{GUID of existing proj ref goes here...}</Project>
    <Name>SomeLibrary</Name>
</ProjectReference>



Platform-Specific Binary (.dll) References:

<Reference Include="SomeDll, Version=..., Culture=..., PublicKeyToken=..., processorArchitecture=x86" Condition="'$(Platform)' == 'x86'" />
    <SpecificVersion>False</SpecificVersion>
    <HintPath>C:\MyAppReferences\x86\SomeLibrary.dll</HintPath>
</Reference>

<Reference Include="SomeDll, Version=..., Culture=..., PublicKeyToken=..., processorArchitecture=x64" Condition="'$(Platform)' == 'x64'" />
    <SpecificVersion>False</SpecificVersion>
    <HintPath>C:\MyAppReferences\x64\SomeLibrary.dll</HintPath>
</Reference>


Share

Wednesday, January 26, 2011

Want to have "WinDbg and SOS-like" features in VisualStudio?

While I've become adept at using WinDbg and all of it's extensions to do post-mortem crash-dump analysis, I've not yet ventured down the path of live-debugging strictly with WinDbg.  Maybe I'm dense, but it's anything but intuitive to me.  Call me "new-school" but there's just something about having a real UI while debugging that makes me more productive.

So, if you've ever needed to use some functionality of WinDbg or SOS (and any of the other extensions) while debugging in VisualStudio, there is some hope...

I've added 2 feature suggestions on the Microsoft Connect website for two features:
  1. View an object's rooted references at runtime - https://connect.microsoft.com/VisualStudio/feedback/details/637376/add-feature-to-debugger-to-view-an-objects-rooted-references
  2. View an object's memory footprint/usage - https://connect.microsoft.com/VisualStudio/feedback/details/637373/add-feature-to-debugger-to-view-an-objects-memory-footprint-usage
If either of these are something you'd like to see in an upcoming version of VisualStudio, please click the links above and vote for them!


As a side note, if you can't wait for the next version of VisualStudio, there are 2 different workarounds in the meantime:
  1. Load SOS into the Immediate Window as documented here:  http://msdn.microsoft.com/en-us/library/yy6d2sxs.aspx
  2. The other option is to stop at a breakpoint in VisualStudio, and then attach WinDbg in "non-invasive" mode.
While these workarounds seem to be mildly satisfactory, it'd be great if these features were already built in to the VS Debugger - so vote!


Share