locked
Version 0.94 fails on a TFS Build RRS feed

  • Question

  • I am getting errors like this on my TFS Build:

    c:\build-temp\ESP-ScanTrack\ScanTrack Server Integration Build\Binaries\Debug\WCFExtras.Moles.dll : error CS1704: An assembly with the same simple name 'WCFExtras.Moles, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null has already been imported. Try removing one of the references or sign them to enable side-by-side.
    MolesAssemblies\WCFExtras.Moles.dll: (Location of symbol related to previous error)

    I don't get this error when I build locally or when I log into my build machine and do a manual build there.  It is only during a TFS Build.  I am guessing the issue is that TFS Builds copies all the files to a single location (different from the standard location on a manual build).

    Either way, I have broken the build.  I would rather not downgrade (because there were quite a few changes in the upgrade to .94), but I cannot leave the build broken for long.

    Anyone have an idea on what I can do to fix this?

    NOTE: I am running a TFS 2008 Build Agent against a TFS 2008 Server building a Visual Studio 2008 project (ie no 2010 products are installed on my Build Machine).  I had to manually create the file C:\Program Files\MSBuild\v3.5\Custom.After.Microsoft.Common.targets. I copied it from my dev machine (which had it copied from C:\Program Files\MSBuild\4.0\Microsoft.Common.targets\ImportAfter\Microsoft.Moles.After.targets ).

    Monday, September 20, 2010 9:46 PM

Answers

All replies

  • I think you should remove your reference to "c:\build-temp\ESP-ScanTrack\ScanTrack Server Integration Build\Binaries\Debug\WCFExtras.Moles.dll", For 0.94, the moles assembly reference should be under <project_folder>\MolesAssemblies\WCFExtras.Moles.dll.
    Monday, September 20, 2010 11:56 PM
  • Russel is right: starting with v0.94, all Moles Assemblies are referenced from a subfolder MolesAssemblies under the project folder.

    However, this is not the first time that this error occurs so we will continue to improve the MSBuild support to get rid of this (probably by implemeting a custom msbuild task in the next release).


    Jonathan "Peli" de Halleux - Try Pex online at www.pexforfun.com!
    Tuesday, September 21, 2010 12:00 AM
  • But I deleted all that extra stuff from my project already.  The only files that are moles related in my projects are *.moles files. 

    The only reference to the moled dlls are in my references section and point the dlls in the MolesAssemblies folder.

    Where else should I remove references?

    Tuesday, September 21, 2010 4:02 PM
  • I have a guess as to what is causing the issues.

    I have two test projects (one for my DAL project and one for my business project).  Each of them mole the same dlls (ie WCFExtras from the example above).  In the previous version the dlls output did not get copied to the output destination in the TFS Build.  Now that they are just normal references, they both get copied to the destination.  This causes a conflict.  (So, in my example, there are two WCFExtras.moles.dll files.   One from the MyProjectDal.Tests project and one from the MyProject.Tests project.  They are both trying to get to the output folder.  Becuase TFS lumps all the binaries in a single place (who's idea was that anyway?) the two files conflict.

    So, if my guess is right and these two files are fighting, then what do I do to fix it?  How can I say, don't copy these files to the output (I don't need my unit test binaries as output from my build).

    Tuesday, September 21, 2010 5:21 PM
  • Ha excellent observation. Let me understand this:

    * MyProjectDal.Tests and MyProject.Tests are two separated unit tests. They do not reference each other. Is that correct? 
    * TFS copies the output into the same directory???


    Jonathan "Peli" de Halleux - Try Pex online at www.pexforfun.com!
    Tuesday, September 21, 2010 8:21 PM
  • Right, but let me clarify.

    * MyProjectDal.Tests and MyProject.Tests are two separate unit test projects .  And no, they do not reference each other, but they do both mole the same dlls (other parts of my project like the WCFExtras mole listed above).

    * It is standard for TFS Build to copy the output of all the projects of the build into a single directory (though some web based projects are the exception to this rule).  This is something that is ingrained in TFS Build is very very hard to disable / customize away (and was a bad design decision in my opinion, but that is a "parking lot" point).

    So, when TFS goes to build (and run) MyTestProjectDal.Tests it now builds WCFExtras.moles and tries to copy it to the output directory.  It does the same thing with MyTestProject.Tests.  When it goes to copy the WCFExtras.moles file from MyTestProject.Tests into the output directory it sees that there is one already in there and chokes.

    I am not 100% sure how this did not choke on pre-0.94 versions, but it did not.  I am guessing that since the moles dlls were not actually built by MSBuild they did not get copied to the traditional output location, so there was no conflict.

    Tuesday, September 21, 2010 8:33 PM
  • So.....

    Any ideas on this?  Is a fix in the works?  Or is this not a high priority?

    I suppose I can try to limit myself to only testing a dll in a single unit, but that is not optimal.

    Any update would be nice.

    Sunday, September 26, 2010 12:01 AM
  • We lost track of this issue. We are implementing a custom msbuild task for Moles that will ensure that references stay unique. Currently, the issue is that Moles always adds the .dlls from the MolesAssemblies folder - even when they've already been resolved from another location.
    Jonathan "Peli" de Halleux - Try Pex online at www.pexforfun.com!
    Sunday, September 26, 2010 11:19 PM
  • Is this something that is planned for the next version or "later down the road"?

    It if is soon then I will wait, if not then I will change my project to try to work around this.

    Monday, September 27, 2010 6:45 PM
  • Fixing MSBuild issue is the #1 item on the list. This one is part of it. It will probably take 2 weeks to get a new release out.


    Jonathan "Peli" de Halleux - Try Pex online at www.pexforfun.com!
    Monday, September 27, 2010 8:15 PM
  • A collegue pointed me to this gem: http://blogs.msdn.com/b/jimlamb/archive/2010/04/13/customizableoutdir-in-tfs-2010.aspx

    We are pushing a release soon.


    Jonathan "Peli" de Halleux - Try Pex online at www.pexforfun.com!
    Wednesday, October 6, 2010 5:24 AM
  • We also see this problem on a TFS 2010 build. Like Vaccanoll, we don't see any errors on our dev machines, VS 2010 builds the code fine and all the tests pass. However automated or manually triggered TFS 2010 builds fail with multiple warnings like this:

     C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Common.targets (1360): Resolved file has a bad image, no metadata, or is otherwise inaccessible. Could not load file or assembly 'System.Data.Linq.Moles' or one of its dependencies. An attempt was made to load a program with an incorrect format.

    and errors like this:

    c:\Builds\1\D4\D4 Dev0\Binaries\mscorlib.Behaviors.dll: An assembly with the same identity 'mscorlib.Behaviors, Version=0.94.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' has already been imported. Try removing one of the duplicate references.

    Looking at the MSBuild log file shows this:

    ResolveAssemblyReferences:
      Primary reference "Logger.Moles".
    C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Microsoft.Common.targets(1360,9): warning MSB3246: Resolved file has a bad image, no metadata, or is otherwise inaccessible. Could not load file or assembly 'Logger.Moles' or one of its dependencies. An attempt was made to load a program with an incorrect format. [C:\Builds\1\D4\D4 Dev0\Sources\Src\Extensions\LoggerTests\LoggerTests.csproj]
          Resolved file path is "C:\Builds\1\D4\D4 Dev0\Sources\Src\Extensions\LoggerTests\Logger.Moles".
          Reference found at search path location "{RawFileName}".
              For SearchPath "{HintPathFromItem}".
              Considered "MolesAssemblies\Logger.Moles.dll", but it didn't exist.
              (Many more Considered... lines removed for brevity)

    So it appears to know it should look in the MolesAssemblies folder. If I look in the <blah>\LoggerTests\MolesAssemblies dir on my build machine, sure enough it contains both System.Data.Linq.Moles.dll and System.Data.Linq.Moles.xml. So why can't it find the Moles dll?

    A little further down the MSBuild log file we see:

    MolesGenerateBeforeBuild:
      
      Generating 4 Moles assemblies with 3 concurrent processes
      <snip for brevity>
      3:end> System.Data.Linq.moles Success (0 - 0x0)

      
       Moles compilation SUCCESS - 14.3604790552989s

    So, to me, it looks like the issue is that the MolesGenerateBeforeBuild task happens AFTER the ResolveAssemblyReferencesTask rather than before it and thus MSBuild can't find the required references.

    Cheers,

    Richard

    • Edited by Richard Partridge Wednesday, October 6, 2010 4:00 PM Removed unwanted copy
    Wednesday, October 6, 2010 3:58 PM
  • The warning is expected and benign. Moles needs to know about the test project references before being able to compile the Moles assembly - so it makes sense to place the generation after MSBuild tried to resolve the reference. Then, Moles generates the missing assemblies and updates the references list. This is where the 'error' happens where a duplicate reference is added.

    We are pushing a new release that solves the error (duplicate reference).


    Jonathan "Peli" de Halleux - Try Pex online at www.pexforfun.com!
    Wednesday, October 6, 2010 4:16 PM
  • We just released Pex v0.94.51006.1 that should fix your issues.

     


    Jonathan "Peli" de Halleux - Try Pex online at www.pexforfun.com!
    Friday, October 8, 2010 12:23 AM
  • Peli,

    I have the latest version of pex and moles (0.94) installed on my TFS 2010 (SC and Build). I also checked GAC to make sure I have ExtendedReflection, Moles and Pex 0.94 there - and sure they are there. I have the same version of pex and moles on my development machine as well.

    Unit tests are run perfectly on the dev machine. However, they fail during TFS build wherever I am using moles. I noticed that Moled assemblies (including the MolesAssemblies folder) are generated successfully on the build server (I don't have them checked-into source control) and then copied over to build output folder but Tests all fail with the following error messages.

    Initialization method XXXXX threw exception. Microsoft.Moles.Framework.Moles.MoleInvalidOperationException: Microsoft.Moles.Framework.Moles.MoleInvalidOperationException: Moles requires tests to be an instrumented process.

    All my test method are decorated with [TestMethod] attribute.

    Any workaround appreciated.

    Tuesday, November 9, 2010 8:46 PM
  • Do you also have [Microsoft.VisualStudio.TestTools.UnitTesting.HostType("Moles")] added to those function that are using moles to the unit tests? Are these generated by Pex per chance, or are you just using Moles?
    Wednesday, November 10, 2010 10:07 PM
  • Yes HostType is also applied.

            [TestMethod]
            [HostType("Moles")]

    They run successfully locally and fail on TFS build.

    Wednesday, November 10, 2010 10:45 PM
  • We have the same problems with our environment: pex and moles (0.94.51006.1) and TFS 2008.

    The error I get is as follows:

    Test method XXX.YYY threw exception: 
    Microsoft.Moles.Framework.Moles.MoleInvalidOperationException: Moles requires tests to be an instrumented process.
    
    In Visual Studio Unit Test, add the following attribute to your unit test method:
    
    [TestMethod]
    [HostType("Moles")] // add this attribute
    public void Test() { ... }
    
    Extensions are also available for most unit test frameworks. Please refer to the Moles manual.

    All tests do have the following annotations:

            [TestMethod]
            [HostType("Moles")]

    These unit tests were running fine before, but after updating the solution to .Net 4.0 and migrating to VS2010 we get these issues on a TFS build. On the local development machine it all works fine.

    Any solution to this problem?

     

     

    Thursday, November 18, 2010 11:07 AM
  • Re-installing pex and moles fixed the issue.

    Maybe this is an issue with pex upgrade from earlier version. After upgrade from 0.91 to 0.94, all unit test codes built successfully (on TFS build machine) but failed during execution of tests. All required assemblies were registered properly in the GAC as I verified.

    I installed pex 0.94 once more and did the trick.

    Hope this help others too.

    • Proposed as answer by Lord Of Agony Sunday, November 21, 2010 12:23 AM
    Sunday, November 21, 2010 12:23 AM