I'm using NServiceBus in a complicated solution (150+ projects, many of them use NSB). Up until last night, when I couldn't stand it anymore, every project had it's own target directories (./bin/debug and ./bin/release). Because of the dependencies between my projects, I was building and rebuilding the same binaries many times over, so we decided to change to a shared output directory for the whole thing, which dramatically improves the build time of the solution. So far so good...
However, when I tried to start up my project, it fails to start giving me the error:
Warning 1 : 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. C:\Program Files (x86)\MSBuild\12.0\bin\Microsoft.Common.CurrentVersion.targets 1697 5 My.Assembly.Goes.Here
Uh, oh. So, I dutifully turn up the log verbosity, clean and rebuild the whole mess, to find this in the log output:
30>------ Build started: Project: My.Assembly.Goes.Here, Configuration: Debug Any CPU ------
28>Building with tools version "12.0".
<Lots of stuff omitted...>
28> There was a conflict between "mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" and "mscorlib, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e, Retargetable=Yes".
28> "mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" was chosen because it was primary and "mscorlib, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e, Retargetable=Yes" was not.
28> References which depend on "mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" [C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5.1\mscorlib.dll].
<etcetera...>
Out comes Dependency Walker (great tool, btw). OK, so what's depending on the old 2.0 framework? Look for every reference to mscorlib and ... One of these things is not like the other...
NServiceBus.Hosting.Azure takes a dependency on Ionic.Zip.dll which, in turn, takes a dependency on the 2.0.0.0 version of mscorlib.dll. Ouch. FWIW, the version of NServiceBus.Hosting.Azure that does so is 5.3.2.0.
This looks to me to be similar to the issue here: https://github.com/Particular/NServiceBus/issues/664
Can I get around this with an Assembly Binding Redirect? Is there some way for me to tell NSB to tell Ionic.Zip.dll that the 4.0.0.0 version of mscorlib.dll is fine, thank you very much?
Or is this an NSB bug?
Thanks in advance.
A binding redirect on mscorlib should work in my opinion, or you could try a binding redirect on a newer version of dotnetziplib (Ionic) that targets 4.0
Related
I'm trying to use WixSharp with .net 4, but I got this warning:
Warning The currently targeted framework ".NETFramework,Version=v4.0,Profile=Client" does not include "System.Design, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" which the referenced assembly "WixSharp, Version=1.0.39.0, Culture=neutral, PublicKeyToken=3775edd25acc43c2, processorArchitecture=MSIL" depends on. This caused the referenced assembly to not resolve. To fix this, either (1) change the targeted framework for this project, or (2) remove the referenced assembly from the project.
I checked that System.Design is not referenced. When I tried to add reference to it, it's actually grayed out in add reference dialog.
As a result, just as the warning says, WixSharp is not resolved, and all namespaces in WixSharp has a missing of reference error.
How should I fix this? compile WixSharp from source?
Fei
I am working with mono-3.0.10 on a Macbook. In the mono 3.0 release note, Tpl.Dataflow is mentioned, and I also noticed that the source code of Tpl.Dataflow is there in mono's github repo master branch.
But I couldn't find it in my local mono install.
logan#Logans-MBA /Library/Frameworks/Mono.framework
{13-06-04 3:47:48} $ find . -name "*.Dataflow.*"
./Versions/3.0.10/lib/mono/4.5/System.Threading.Tasks.Dataflow.dll
logan#Logans-MBA /Library/Frameworks/Mono.framework
{13-06-04 3:59:55} $ file ./Versions/3.0.10/lib/mono/4.5/System.Threading.Tasks.Dataflow.dll
./Versions/3.0.10/lib/mono/4.5/System.Threading.Tasks.Dataflow.dll: broken symbolic link to ../gac/System.Threading.Tasks.Dataflow/4.0.0.0__b77a5c561934e089/System.Threading.Tasks.Dataflow.dll
I have tried reinstall the mono from installer, but no luck.
Then, I tried the dlls downloaded from nuget, the following errors comes:
/Users/logan/Workspace/Camp/Dragon/ClientEventHandlerDemos/DataflowBlockClientEventHandler.cs(11,13): error CS0012: The type `System.Object' is defined in an assembly that is not referenced. Consider adding a reference to assembly `System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
/Users/logan/Workspace/Camp/Dragon/ClientEventHandlerDemos/DataflowBlockClientEventHandler.cs(11,34): error CS0012: The type `System.Action`1<TInput>' is defined in an assembly that is not referenced. Consider adding a reference to assembly `System.Runtime, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
There are 3 editions from nuget, net45, netcore45 and portable-net45. I tried them all, but still no luck.
So, where could I find the right update to date Tpl.Dataflow works with mono?
I build VS2010 projects with Mono's xbuild 2.10.5.0. The projects use the '.NET Framework 3.5 Client Profile' as the target framework (they must be 3.5 compatible and I don't need more than the client profile parts).
I'm getting the following warnings:
Build succeeded.
Warnings:
c:\Project\MyProject.csproj (default targets) -> C:\PROGRA~2\Mono\lib\mono\4.0\Microsoft.Common.targets (GetReferenceAssemblyPaths target) ->
C:\PROGRA~2\Mono\lib\mono\4.0\Microsoft.Common.targets: warning : Unable to find framework corresponding to the target framework moniker '.NETFramework,Version=v3.5,Profile=Client'. Framework assembly references will be resolved from the GAC, which might not be the intended behavior.
c:\Project\MyProject.csproj (default targets) -> C:\PROGRA~2\Mono\lib\mono\4.0\Microsoft.Common.targets (ResolveAssemblyReferences target) ->
C:\PROGRA~2\Mono\lib\mono\4.0\Microsoft.Common.targets: warning : Reference 'mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' not resolved
C:\PROGRA~2\Mono\lib\mono\4.0\Microsoft.Common.targets: warning : Found a conflict between : 'System' and 'System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'. Using 'System' reference.
C:\PROGRA~2\Mono\lib\mono\4.0\Microsoft.Common.targets: warning : Found a conflict between : 'System.Core' and 'System.Core, Version=3.5.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'. Using 'System.Core' reference.
I'm afraid I don't understand these and the only Google hit for "Unable to find framework corresponding to the target framework moniker" is the commit for that error message.
What do these warnings mean and how can I fix them? Is the 'client profile' not supported by Mono at all? If so, I couldn't find anything about that in the Mono documentation. What causes the unresolved mscorlib reference and where are these two System references it reports a conflict between?
You are guessing correctly - Mono does not support the 'Client' profile (e.g. search Mono version of 3.5 Microsoft.Common.targets for any mention of 'Client'), only the full 3.5 and 4.0 profiles. To fix them, you need to specify one of the supported profiles in your project file. Profile selection only restricts the set of references available during build, an assembly compiled with the 'Client' profile will work on the 'Full' profile just fine.
The mscorlib, Version=2.0.0.0 unresolved reference is happening because you are compiling with a 4.0 profile (which is the default fallback). It will disappear once you set your profile to a supported value. If you do not want to change your project file, you can build with xbuild /p:TargetFrameworkProfile="", which correctly chooses the 3.5 set of assemblies.
I am building an application using NHibernate. Because I could not add the DLL's of my current version of NHibernate (I cannot add reference when framework 4.0 is target).
I tried to get the latest and greatest of the w.w.w., this is what I have now:
NHibernate.dll (3.2.0.4000)
NHibernate.ByteCode.Castle (3.0.0.4000)
FluentNHibernate.dll (1.2.0.694)
Castle.Core (2.5.2.0)
Castle.Services.Logging.NLogIntegration (2.5.2.0)
Antlr.Runtim (3.1.3.42154)
Iesi.Collections (3.2.0.400)
These I can reference and build my solution with. I know there are some issues with the copying/loading of the dll.s so I made them deployment items.
But run-time I (still) get the following:
NHibernate.Bytecode.UnableToLoadProxyFactoryFactoryException: Unable to load type 'NHibernate.ByteCode.Castle.ProxyFactoryFactory, NHibernate.ByteCode.Castle' during configuration of proxy factory class.
Possible causes are:
- The NHibernate.Bytecode provider assembly was not deployed.
- The typeName used to initialize the 'proxyfactory.factory_class' property of the session-factory section is not well formed.
Solution:
Confirm that your deployment folder contains one of the following assemblies:
NHibernate.ByteCode.LinFu.dll
NHibernate.ByteCode.Castle.dll ---> System.TypeLoadException: Method 'IsProxy' in type 'NHibernate.ByteCode.Castle.ProxyFactoryFactory' from assembly 'NHibernate.ByteCode.Castle, Version=3.0.0.4000, Culture=neutral, PublicKeyToken=aa95f207798dfdb4' does not have an implementation.
Thoughts anyone?
In response to Vijay Gill’s answer I have decided to take a different tack.
NUGet packages, a one-stop shop, and easy updates!
There is a FluentNHibernate package out there. I have installed it but I guess there is something amiss here too:
Test method CoreDatabaseTests.CreateCoreDatabase threw exception:
System.IO.FileLoadException: Could not load file or assembly 'NHibernate, Version=3.2.0.4000, Culture=neutral, PublicKeyToken=aa95f207798dfdb4' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040) ---> System.IO.FileLoadException: Could not load file or assembly 'NHibernate, Version=3.1.0.4000, Culture=neutral, PublicKeyToken=aa95f207798dfdb4' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference.
With NHibernate 3.2 you don't need NHibernate.ByteCode.Castle anymore, which considerably simplifies your dependency tree.
Getting components from various locations in such cases is nto a good idea, you compile everything from scratch. Well that's my experience so far. Fluent NH has not been updated to NH 3.2GA.
I would suggest you to download fluent NH and stick with the version that comes with it OR if you want to be on the bleeding edge, download the sources of fluent NH and compile with references set to latest NH (3.2GA).
Could not load file or assembly 'NHibernate, Version=3.2.0.2002, Culture=neutral, PublicKeyToken=aa95f207798dfdb4' or one of its dependencies. The system cannot find the file specified.
This could be caused by a number of things, but the most probable cause is that your start up project does not reference the assembly 'NHibernate, Version=3.2.0.2002, Culture=neutral, PublicKeyToken=aa95f207798dfdb4' although other assemblies you have referenced use the assembly.
Add the assembly to the start up project and you shall be fine.
And please try to ask questions in a better manner.
It seems FHN has not a build for NH 3.2 yet, because it's in RC state right now.
So you can use asm binding redirect for now.