Welcome Guest! To enable all features please Login or Register.

Notification

Icon
Error
Build failed with "SpecificVersion=True"
Options
Previous Topic Next Topic
karpik
#1 Posted : Wednesday, July 4, 2012 8:56:24 AM(UTC)
Rank: Newbie

Groups: Registered
Joined: 7/4/2012(UTC)
Posts: 2

Was thanked: 1 time(s) in 1 post(s)
Hi,
I have a .Net 2.0 solution, one of the dependencies is inderectly dependent on .Net 3.5. solution for it to build is to specify <SpecificVersion>True</SpecificVersion> in References.
I think it's a known issue in Visual Studio 2010.

NCrunch ignores that setting :(

Is there a way to set that specific version in NCrunch csproj? Or maybe modify the NCrunch version of csproj file on the fly?
Back to top
Remco
#2 Posted : Thursday, July 5, 2012 1:19:26 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 6,986

Thanks: 931 times
Was thanked: 1257 time(s) in 1170 post(s)
Hi, thanks for posting!

At the moment NCrunch doesn't consider this option, so it will be stripped out of the assembly/project reference in the .proj file that NCrunch constructs in order to build your project. With the current version of NCrunch, I'm not sure of any way you can work around this short of changing your solution structure to avoid the 2.0->3.5 dependency (which I assume will be very expensive for you).

If you can share the XML markup in the .proj file that is used to specify the reference, I'll take a closer look and will see if there's any way I can resolve this in a future version.


Thanks!

Remco
Back to top
karpik
#3 Posted : Thursday, July 5, 2012 6:30:34 AM(UTC)
Rank: Newbie

Groups: Registered
Joined: 7/4/2012(UTC)
Posts: 2

Was thanked: 1 time(s) in 1 post(s)
It would be cool if you provided a way to run custom action after creating csproj file (maybe a XSLT transform?)

the reference looks like this:
Code:

    <Reference Include="ABC, Version=1.2.3.4, Culture=neutral, PublicKeyToken=0ada19204fdf1f6a, processorArchitecture=MSIL">
      <HintPath>..\ThirdPartyLibraries\ABC\1.2.3.4\ABC.dll</HintPath>
      <SpecificVersion>True</SpecificVersion>
    </Reference>
Back to top
1 user thanked karpik for this useful post.
Remco on 7/6/2012(UTC)
keith
#4 Posted : Tuesday, December 24, 2013 3:33:53 AM(UTC)
Rank: Newbie

Groups: Registered
Joined: 12/24/2013(UTC)
Posts: 9
Location: Australia

Was thanked: 1 time(s) in 1 post(s)
Hi Guys,

FYI we're running into the same issue with the SpecificVersion attribute.

Keith
Back to top
Remco
#5 Posted : Tuesday, December 24, 2013 6:22:54 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 6,986

Thanks: 931 times
Was thanked: 1257 time(s) in 1170 post(s)
Hi Keith -

Can you share any more details about how you are making use of SpecificVersion? Are you using this for a project reference?

Right now NCrunch considers SpecificVersion when it loads projects, then stores the appropriate assembly reference for later use when building the project. If your project is resolving to the wrong reference, there may be something else going on here.
Back to top
keith
#7 Posted : Friday, December 27, 2013 7:37:01 AM(UTC)
Rank: Newbie

Groups: Registered
Joined: 12/24/2013(UTC)
Posts: 9
Location: Australia

Was thanked: 1 time(s) in 1 post(s)
Hi Remco,

Thanks for the reply. We are using the SpecificVersion attribute for a project reference. Details of our scenario are as follows:

We've got a class library project which we compile using a different target framework version depending on the build configuration. E.g. we have a "Debug.35" build which uses a TargetFrameworkVersion of v3.5 and a "Debug.45" build which uses a TargetFrameworkVersion of v4.5. We are doing this to have a single codebase that we can use for both SharePoint 2010 and SharePoint 2013 solutions.

This class library is referenced by a unit test project using a project reference (with the SpecificVersion attribute). The test project builds, and the tests run fine using the Visual Studio test runner but fail to build in NCrunch with the following error:

The name 'xyz' does not exist in the current context.

If we remove the SpecificVersion attribute from the project reference we see the same behaviour - the projects fail to build in Visual Studio.

The project reference (in our unit test project, referencing the class library) is set up as follows:

Code:
    <ProjectReference Include="..\Acme.ClassLib\Acme.ClassLib.csproj">
      <Project>{guid-here}</Project>
      <Name>Acme.ClassLib</Name>
      <SpecificVersion>true</SpecificVersion>
    </ProjectReference>


Let me know if you need any more information or if you want me to send through a hello world solution that reproduces this.

Cheers,

Keith
Back to top
 |  Edit by user
Remco
#8 Posted : Friday, December 27, 2013 11:49:49 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 6,986

Thanks: 931 times
Was thanked: 1257 time(s) in 1170 post(s)
Thanks Keith - this is starting to make more sense now.

When NCrunch analyses your solution, it traverses the relationships between projects and stores them as part of its working model. These relationships are then simplified into assembly references inside NCrunch's workspaces. You'll notice if you look at one of the generated .csproj files inside an NCrunch workspace that it doesn't contain project references - only assembly references to very specific DLL files controlled carefully by NCrunch.

When NCrunch identifies relationships between projects, it does this based on the location of the .csproj files. So if your project is said to reference another project at '..\Acme.ClassLib\Acme.Classlib.csproj', then NCrunch will hook up this reference completely regardless of any other attributes.

One way I could see this failing is if you have a project that is somehow included twice within the solution. So basically, one .csproj file that is represented twice inside Visual Studio that can compile into two different versions. I'm not sure how to create a scenario like this as I've never seen it done before, but do let me know if this is something you're working with at the moment.

If you haven't seen it, I would also recommend having a look at the documentation page that describes how NCrunch works with platform/configuration settings inside Visual Studio. I mention this as your description of your setup suggests that this might give you trouble if it isn't addressed, and it may be related to the problem you're experiencing.

If you can create a cut-down 'hello world' solution to produce the problem, this would be enormously helpful. Assembly/project referencing can become very complex in some situations and with a dummy solution to reproduce the issue, I should be able to help solve it for you very quickly.

Cheers,

Remco
Back to top
keith
#9 Posted : Tuesday, December 31, 2013 12:06:22 AM(UTC)
Rank: Newbie

Groups: Registered
Joined: 12/24/2013(UTC)
Posts: 9
Location: Australia

Was thanked: 1 time(s) in 1 post(s)
Hi Remco,

Thanks again for your assistance with this.

My "Hello World" project seems to build just fine with NCrunch so I'll have try building it out a bit more to try to reproduce the issue.

FYI when I browse to the NCrunch workspace and open the CSPROJ file it fails to build with the following errors:

Code:
An assembly with the same identity 'mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' has already been imported. Try removing one of the duplicate references.	c:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\mscorlib.dll	Qualitem.Publishing.Tests
An assembly with the same identity 'System.Core, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' has already been imported. Try removing one of the duplicate references.	c:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\System.Core.dll	Qualitem.Publishing.Tests


As I mentioned earlier, we are targeting two version of .NET with the one CSPROJ file. We set the TargetFrameworkVersion based on the build configuration - so one build configuration compiles with 3.5, another with 4.5. I've set this up in my "Hello World" project and it works just fine so there must be something else going on. I'll let you know if I have any luck reproducing it.

Cheers,

Keith
Back to top
Remco
#10 Posted : Tuesday, December 31, 2013 6:39:13 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 6,986

Thanks: 931 times
Was thanked: 1257 time(s) in 1170 post(s)
Thanks Keith! I have a feeling that this issue is nested pretty deeply in your solution structure and it may take some digging to bring it out. Let me know as soon as you have any code you can send me to make it happen.

The .csproj file you'll find in the NCrunch workspace is designed to be built using a command-line invocation of MSBuild. Probably it will fail to be loaded by Visual Studio, which has its own very different logic for processing .proj files and interpreting their contents. Something that may help with troubleshooting is to try an MSBuild.exe invocation against the generated .csproj file. Knowledge of whether or not the file builds correctly like this will be very useful in narrowing down where the problem lies.
Back to top
keith
#11 Posted : Thursday, January 16, 2014 5:58:08 AM(UTC)
Rank: Newbie

Groups: Registered
Joined: 12/24/2013(UTC)
Posts: 9
Location: Australia

Was thanked: 1 time(s) in 1 post(s)
Hey Remco,

I've found out a bit more info in the last few weeks - unfortunately it's still not building on my machine.

The first thing is that one of my colleagues has also started using nCrunch and everything is working just fine on her machine. There's nothing unusual going on in our development environment - we're both using VS2013 (without any other add-ins), using TFS for source control so it's the exact same code that nCrunch is trying to build. It's strange that it'd be working on one machine and not the other.

I've tried uninstalling nCrunch and reinstalling, upgrading to the beta version etc and get the same result.

When I try to build the test project from the nCrunch workspace using msbuild I get a load of warnings (I think almost every assembly we're referencing comes back with one of these warnings):

C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(1605,5): warning MSB3258: The primary reference "C:\Users\Administrator\AppData\Local\NCrunch\5988\14\Acme.Publishing.Core\bin\Debug.2010\Acme.Publishing.Core.dll" could not be resolved because it has an indirect dependency on the .NET Framework assembly "mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" which has a higher version "4.0.0.0" than the version "2.0.0.0" in the current target framework. [C:\Users\Administrator\AppData\Local\NCrunch\5988\18\Acme.Publishing.Tests\Acme.Publishing.Tests.csproj]
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(1605,5): warning MSB3258: The primary reference "C:\Users\Administrator\AppData\Local\NCrunch\5988\15\Acme.Publishing\bin\x64\Debug.2010.35\Acme.Publishing.dll" could not be resolved because it has an indirect dependency on the .NET Framework assembly "mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" which has a higher version "4.0.0.0" than the version "2.0.0.0" in the current target framework. [C:\Users\Administrator\AppData\Local\NCrunch\5988\18\Acme.Publishing.Tests\Acme.Publishing.Tests.csproj]
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(1605,5): warning MSB3258: The primary reference "C:\Users\Administrator\AppData\Local\NCrunch\5988\14\Acme.Publishing.Core\bin\Debug.2010\Acme.Publishing.Core.dll" could not be resolved because it has an indirect dependency on the .NET Framework assembly "System.Core, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" which has a higher version "4.0.0.0" than the version "3.5.0.0" in the current target framework. [C:\Users\Administrator\AppData\Local\NCrunch\5988\18\Acme.Publishing.Tests\Acme.Publishing.Tests.csproj]

And a number of errors - all the same error:

Services\PublishingServiceTests.cs(7,27): error CS0234: The type or namespace name 'Core' does not exist in the namespace 'Acme.Publishing' (are you missing an assembly reference?) [C:\Users\Administrator\AppData\Local\NCrunch\5988\18\Acme.Publishing.Tests\Acme.Publishing.Tests.csproj]

Note that all the projects in our solution build fine with nCrunch other than the test projects. Let us know if you've got any ideas about anything else we can check or things we can try..

I haven't been able to reproduce the issue in a "Hello World" project - everything I try seems to build just fine (and as I mentioned, the same code is building / crunching on my colleague's machine).

Cheers,

Keith
Back to top
Remco
#12 Posted : Thursday, January 16, 2014 6:16:02 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 6,986

Thanks: 931 times
Was thanked: 1257 time(s) in 1170 post(s)
Hi Keith,

Thanks for sharing the extra info. I think we're getting closer on this.

I'm wondering if you could share some more details on how your test projects are configured. My understanding is that you have at least one project in your solution that can build to either v2 or v4 of the .NET framework, as controlled by the $(Configuration) MSBuild property that is injected from Visual Studio when it builds this project.

So if you are running a Debug.35 build, the project is built with .NET 2.0 metadata, and with Debug.45 it will be built with .NET 4.0 metadata.

This means that for your test project to be able to reference this project, it must be built with .NET 4.0 metadata. Do you have any $(Configuration) specific controls inside this test project? I'm wondering if it's possible that NCrunch's handling of the $(Configuration) property results in the test projects being built with v2 metadata, while the project under test is built with v4.

Try this:

- Disable NCrunch
- Open the NCrunch configuration pane
- Select ALL the projects in your solution using multi-selection
- Look for the Use build configuration configuration setting
- Set this value to Debug.45 for ALL of your projects

Does this resolve the issue?
Back to top
keith
#13 Posted : Thursday, January 16, 2014 7:27:19 AM(UTC)
Rank: Newbie

Groups: Registered
Joined: 12/24/2013(UTC)
Posts: 9
Location: Australia

Was thanked: 1 time(s) in 1 post(s)
Fantastic, thanks Remco! That's fixed it.

FYI we are using $(Configuration) in a few locations within our CSPROJ files (both the application and the test projects).

Firstly to set the Target Framework Version - e.g.

<PropertyGroup Condition=" '$(Configuration)' == 'Release.2013' ">
...
<TargetFrameworkVersion>v4.5</TargetFrameworkVersion>
</PropertyGroup>

Also we've got conditional references set up. The main reason for this is that we need to reference different versions of some dependencies depending on the build configuration. For example (simplified a bit):

<Choose>
<When Condition="'$(Configuration)'=='Debug.2010' Or '$(Configuration)'=='Release.2010''">
<ItemGroup>
<Reference Include="..." />
</ItemGroup>
</When>
<When Condition="'$(Configuration)'=='Debug.2013' Or '$(Configuration)'=='Release.2013'">
<ItemGroup>
<Reference Include="..." />
</ItemGroup>
</When>
</Choose>

Love your work with nCrunch (and also the support). Thanks again.
Back to top
Remco
#14 Posted : Thursday, January 16, 2014 11:25:00 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 6,986

Thanks: 931 times
Was thanked: 1257 time(s) in 1170 post(s)
Great stuff! I'm glad that did the trick!

Something I can recommend is to also look at the defaults that are specified in your .csproj files for the $(Configuration) value. Visual Studio doesn't use these, but many other tools (such as NCrunch) do rely on them. Generally you want the default values to be set to a configuration that can be used to build the solution in debug mode and be able to run all tests. Of course, this isn't strictly needed now that you have the configuration set up in NCrunch, but it may be worth looking at in future in case you have trouble with other tools or if the NCrunch configuration gets lost somehow. Configuration/Platform related issues can sometimes give some very misleading errors and waste huge amounts of time.

I'm glad you're enjoying NCrunch :)


Cheers,

Remco
Back to top
Users browsing this topic
Guest
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.

YAF | YAF © 2003-2011, Yet Another Forum.NET
This page was generated in 0.095 seconds.
Trial NCrunch
Take NCrunch for a spin
Do your fingers a favour and supercharge your testing workflow
Free Download