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

Notification

Icon
Error

The project currently contains references to more than one version of <AssemblyName>
DanAtkinson
#1 Posted : Friday, June 30, 2017 8:15:54 AM(UTC)
Rank: Newbie

Groups: Registered
Joined: 2/8/2017(UTC)
Posts: 3
Location: United Kingdom

Hi there,

Occasionally, when I'm making a lot of quickfire changes to code and tests, NCrunch will get itself in a pickle and will start throwing build errors such as the following:

Quote:
The project currently contains references to more than one version of '<AssemblyName>', a direct reference to version 1.7.0.15007 and an indirect reference to version 1.7.0.23337. Change the direct reference to use version 1.7.0.23337 (or higher) of <AssemblyName>.


And finally:

Quote:
WARNING - C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\Bin\Microsoft.Common.CurrentVersion.targets: MSB3277: Found conflicts between different versions of the same dependent assembly that could not be resolved. These reference conflicts are listed in the build log when log verbosity is set to detailed.


Where <AssemblyName> is the name of my assembly, such as Dan.Models.

In my AssemblyInfo.vb, I have the following:

Quote:
<Assembly: AssemblyVersion("1.7.0.*")>


The only way to resolve this is usually either to disable NCrunch or close Visual Studio, and then delete the folder that it builds the solution in. Once that's done, re-enabling NCrunch or restarting VS will fix the issue.

I can't remove the AssemblyVersion attribute so am left with submitting this bug instead.

Any help in resolving this would be greatly appreciated.

Thanks, Dan
Remco
#2 Posted : Wednesday, July 05, 2017 12:43:03 PM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 5,277

Thanks: 695 times
Was thanked: 856 time(s) in 814 post(s)
Hi Dan,

Thanks for sharing this issue. It may be difficult to recreate the mechanics involved here to get a clear picture of exactly how the build system is arriving in this situation, but I would guess that having an assembly version that changes on every build is probably causing some dependency issues inside the NCrunch workspaces. NCrunch's build system is probably reliant on an assembly being built with a consistent version number.

The only way I can think of to fix this would be to suppress your usage of the AssemblyVersionAttribute under NCrunch builds. Understanding that you can't remove this attribute in your normal build system, the solution would instead be to make it conditional on not being an NCrunch build. Under C#, this would be as simple as using the #!NCrunch directive to just block it out of the build. Unfortunately NCrunch doesn't have an equivalent to this under VB, so the simplest way may be to just remove your AssemblyInfo.vb file from NCrunch's build.

Inside your project XML, you'll see something like this:

<ItemGroup>
<Compile Include="Properties\AssemblyInfo.cs" />
</ItemGroup>

Try placing this inside an itemgroup with an NCrunch condition, as such:

<ItemGroup Condition="'$(NCrunch)' != '1'">
<Compile Include="Properties\AssemblyInfo.cs" />
</ItemGroup>

By doing this, NCrunch will ignore the AssemblyInfo.cs file and all of its contents. This means that the assembly version will be consistent for each build, and there won't be any version-specific referencing issues.
DanAtkinson
#3 Posted : Monday, June 25, 2018 3:50:59 PM(UTC)
Rank: Newbie

Groups: Registered
Joined: 2/8/2017(UTC)
Posts: 3
Location: United Kingdom

Hi there,

I'm really sorry but I didn't see an answer to this until now when I was looking into the problem again and someone else asked me for it. Turns out I got an email notification but archived it for whatever reason.

Anyway... I hate to dredge this up from over a year ago, but is there any way to be able to handle this in a future version of NCrunch in some way?

The fix suggested is quite messy and means that we pollute non-test projects with hacks for the test project. I don't know why but dotCover (which I usually have disabled) doesn't seem to have this same problem, so whatever the issue is seems to be local to NCrunch only.

It would be great to see some way of handling this in a future version.

Many thanks, Dan
Remco
#4 Posted : Tuesday, June 26, 2018 12:15:28 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 5,277

Thanks: 695 times
Was thanked: 856 time(s) in 814 post(s)
Hi Dan,

I may be able to offer a solution here that doesn't involve introducing hacks to your project files, but you probably won't like it.

To improve performance, NCrunch short-circuits your build system to only build projects that have changed. This is different from the standard VS/MSBuild approach where once a project has changed, ALL of the projects depending on it must also be rebuilt. The difference in performance is very significant on large projects. It can mean the difference between a 2-5 second wait before tests start executing vs a 30-60 second wait when working on projects deep in the solution structure.

When you use a wildcard to change the version of an assembly with every build, you've effectively broken this system, because the assemblies that are reliant on your changed assembly have their references fall out of date as soon as the assembly version is changed. These assemblies then need to be rebuilt.

If you like, you can turn off the above optimisation by changing your 'Copy referenced assemblies to workspace' setting to TRUE for all the projects in your solution. In theory, this should allow NCrunch to work with your solution without the project hacks being necessary, but I would expect this is probably not worth the cost of waiting for the build to run.
DanAtkinson
#5 Posted : Tuesday, June 26, 2018 8:38:41 AM(UTC)
Rank: Newbie

Groups: Registered
Joined: 2/8/2017(UTC)
Posts: 3
Location: United Kingdom

Hi,

You're right. This would very be difficult to accept.

The only sensible thing I can think of that doesn't involve editing all of my projects is that the initially suggested feature is baked into NCrunch as a setting. This would allow users to tell NCrunch to ignore (or overwrite) the Assembly.AssemblyVersion property and this way, any NCrunch builds would either not have the AssemblyVersion property, or perhaps have a default of, say, 1.0.0.0.

Thanks, Dan
Remco
#6 Posted : Tuesday, June 26, 2018 9:11:59 AM(UTC)
Rank: NCrunch Developer

Groups: Administrators
Joined: 4/16/2011(UTC)
Posts: 5,277

Thanks: 695 times
Was thanked: 856 time(s) in 814 post(s)
Hi Dan,

You're welcome to request such a feature on uservoice if you like.
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.055 seconds.