views:

67

answers:

1

I am seeing a strange phenomenon in Visual Studio 2010.

My project setup is this (I inherited this - can't change it any time soon, unfortunately :-():

  • a Winforms app that uses Crystal Reports X (v10) as its reporting engine; full CR X Developer Edition is installed on my dev box

  • several Webforms apps that use Crystal Reports XI (v11) as their reporting engine - cannot install CR XI full version, since it clashes with CR X Dev Edition....

In order to make things work on our build server, I also created a Library folder inside the Winforms app's project directory with the CR X runtime files I need, as well as a Library folder inside the web app's project directory with the CR XI runtime files.

In VS 2008, I was able to pick the necessary assemblies from the respective library folder in my Winforms projects (several class libraries etc.), and in my web apps. Everything worked great.

When I updated to Visual Studio 2010, now suddenly I'm seeing:

  • in my Winforms apps, all the references to CR X runtime files are being automagically updated to use the CR X files from the GAC - this is not what I want! It doesn't help if I delete those references and re-add them again by browsing to the Library folder - when I pick them, VS2010 seems to automagically conver them to GAC references again...

  • in my Web apps, things get even worse: when I pick the CR XI runtime assemblies from the Library folder, again, VS2010 automagically seems to detect there are similar files (same name, but different versions) in the GAC and uses those files instead - now my web apps don't work anymore.....

What the h*** is going on with VS 2010 here?? Why can't it leave my selections alone and let me choose my runtime files from a Library folder instead of insisting on going to the GAC?? What has changed between VS 2008 and VS 2010 in this respect?? Does anyone have any insights into this??

+1  A: 

It may be useful to either

(1) go to Tools\Options\Project&Solutions\Build&Run and change MSBuild verbosity to 'diagnostic' and then build and in the Output window see how the MSBuild reference resolution logic is working for those assemblies. That is, if VS hasn't already done something ridiculous to the underlying .csproj file

(2) compare the XML in the VS2008 project file versus the VS2010 project file to see what's in the <Reference> nodes

A wild speculative guess: the VS2010 project is targeting ".NET 4.0 Client" (rather than ".NET 4.0 (full framework)", and the libraries need the full framework, and MSBuild sees this dependency and is using fallback logic.

Brian
Thanks for the tip with the MSBuild verbosity - it seems to me the trouble starts way before the build, however... Also: no, the VS2010 solution targets .NET 3.5 SP1 just like the VS2008 version.
marc_s