none
Problems building solution file with dependencies using a msbuild.exe - VS2005 network installation RRS feed

  • Question

  • Introduction:

    ------------------

    I am running in to a problem with msbuild.exe attempting to build a solution file (which has couple of project files - one depending on the other). I need help resolving this.  

     

    Detailed information:

    -----------------------------
    I have a solution file containing two projects. One is a managed wrapper dll written in MC++. The other one is a .Net assembly (executable) which depends on the managed wrapper dll. The .Net assembly ???.csproj file is setup in such a way that it has a project reference dependency on the wrapper MC++ dll.

     

    I also have a clean build machine which is connected to a network drive. On the network drive I have VS2005 professional network installation.

     

    Subsequently when I try to build the solution file (from the build machine - VS2005 not installed) using msbuild.exe (with the VS2005 network installation), it complains about Microsoft.VisualStudio.VCProjectEngine.dll not found in the global assembly cache. Note that I setup the VS2005 environment properly using vcvarsall.bat before attempting to run msbuild.exe.

     

    To be more specific, this error occurs during the build process of the .csproj file (.Net assembly). During the build process of the .csproj file, it tries to resolve the referenced managed wrapper dll (.vcproj) file in the "ResolveVCProjectReferences" command sequence. This is when it complains about Microsoft.VisualStudio.VCProjectEngine.dll not being there in the global assembly cache.

     

    If I install Microsoft.VisualStudio.VCProjectEngine.dll in the global assembly cache using the gacutil.exe, things are fine. But this is not desirable from the build machine perspective as we would like to keep it as clean as possible.

     

    Additional info: The build machine does not have VS2005 installed, but does have the .netfx2.0 runtime installed.

     

    Any idea why this failure happens? Possible workarounds/resolution?

     

    Do I need absolutely need to install .netfx SDK 2.0 from/on that build machine? Or can I get away just installing .netfx 2.0 on the network drive (from some other machine) and point to it (i.e include it in the build environment somehow)? If am able to do this, would that be considered inappropriate usage?

     

    Raj

    Friday, June 29, 2007 4:12 PM