ActiveWriter and NHibernate: Can't generate - nhibernate

I'm trying to generate NHibernate mappings with ActiveRecord. I can create classes from a diagram by targeting ActiveRecord, but whenever I target NHibernate, I get the following error:
Error 1 Running transformation: System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.IO.FileNotFoundException: Could not load file or assembly 'NHibernate, Version=1.2.0.4000, Culture=neutral, PublicKeyToken=aa95f207798dfdb4' or one of its dependencies. The system cannot find the file specified.
File name: 'NHibernate, Version=1.2.0.4000, Culture=neutral, PublicKeyToken=aa95f207798dfdb4'
at Castle.ActiveRecord.ActiveRecordStarter.SetUpConfiguration(IConfigurationSource source, Type type, ISessionFactoryHolder holder)
at Castle.ActiveRecord.ActiveRecordStarter.Initialize(IConfigurationSource source, Type[] types)
at Castle.ActiveRecord.ActiveRecordStarter.Initialize(Assembly assembly, IConfigurationSource source)
WRN: Assembly binding logging is turned OFF.
To enable assembly bind failure logging, set the registry value [HKLM\Software\Microsoft\Fusion!EnableLog] (DWORD) to 1.
Note: There is some performance penalty associated with assembly bind failure logging.
To turn this feature off, remove the registry value [HKLM\Software\Microsoft\Fusion!EnableLog].
I am referencing the NHibernate DLL, but it is version 2.0.1.4000 . I added the following into the web.config:
<dependentAssembly>
<assemblyIdentity name="NHibernate" publicKeyToken="aa95f207798dfdb4" culture="neutral"/>
<bindingRedirect oldVersion="1.0.0.0-1.2.0.4000" newVersion="2.0.1.4000"/>
</dependentAssembly>
but it is still trying to grab the old NHibernate DLL. Is there something else that must be done to use the new NHibernate?

I ended up scrapping the idea of using newer NHibernate versions and unpacked all the external dlls from the Castle project into the bin directory of the Castle project. After setting that, I was able to generate NHibernate mappings.

Related

Azure shareclient works in one project and throws exception in another

I have a vb.net solution with a separate project containing a file class to access Azure files and 2 projects. In both I call the file class which contains this code
Dim mascThis as ShareClient
... mascThis is initialized ...
If mascThis.Exists.Value then ... do something ..
In one project this works, in the other I get the message
Could not load file or assembly 'System.Runtime.CompilerServices.Unsafe, Version=4.0.4.1, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
I've seen this problem discussed before (assembly issues), but all projects are in the same solution in to which I added Azure.Storage.Files.Shares 12.8.0 via Nuget and only the "File class" project has a reference to it, the other projects don't.
So what am I missing here?
Please check if any of the below is your case.
Sometimes, we will have the situation where different parts(projects) of our solution depend on different versions of the same DLL i.e; assemblies with the same assembly name.
The error
Could not load file or assembly
'System.Runtime.CompilerServices.Unsafe, Version=4.0.4.1,
Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its
dependencies. The located assembly's manifest definition does not
match the assembly reference. (Exception from HRESULT: 0x80131040)
suggests , your project is looking for assembly version 4.0.4.1
Work arounds
i. Usually Nuget Package 4.5.3 contains assembly version 4.0.4.1.
Please check if both the projects in your solution can be worked on that assembly version and add that particular version as new version(ex:4.0.4.1) through binding redirect in the project where you are getting error. And keep the old version in place of old version.
Also Right click on the package reference and set 'specific version' to false under its properties
Example:
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="System.Runtime.CompilerServices.Unsafe" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-4.0.6.0" newVersion="4.0.6.0" />
</dependentAssembly>
In this example ,this way of adding specifies that the runtime should use version 4.0.6.0 in the Assembly versions between olderversion range 0.0.0.0-4.0.6.0
Else If above is not the case, the solution might need different versions.
ii.
Right click in the project properties and choose the ApplicationConfiguration file and App.config
Add the following settings in the app.config file.
To configure multiple assemblies with the same name through codeBases.
Sample code for some package say “A” :
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="A " publicKeyToken="3d67ed1f87d44c89" />
<codeBase version="3.0" href="...\A.dll"/>
<codeBase version="5.0" href="...\A.dll"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
iii. See if you could solve that problem by using extern alias.
iv. Binding redirects are added if your app or its components reference more than one version of the same assembly .See Enable or disable autogenerated binding redirects | Microsoft Docs .If you do it manually ,you need to disable under project properties.
Manually you can add <AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects> in csproj file in property group.
Ex:
<PropertyGroup>
<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
<GenerateBindingRedirectsOutputType>true</GenerateBindingRedirectsOutputType>
</PropertyGroup>
References that can be helpful.
SO reference
Referencing Multiple Versions
load same assembly of different version-SO

System.Runtime, Version=4.2.1.0, PublicKeyToken=b03f5f7f11d50a3a has a higher version than referenced assembly

I upgraded my ASP.NET CORE application from sdk .NET Core 2.0 to .NET Core 2.1.
I can run the solution in my localhost but when I deploy it to another server there is an exception. And the exception is below.
The steps I have done to solve the issue so far are below and it throws the same error with all the modification that I did seems nothing works.
Does anybody have any suggestion how to solve this issue?
Steps I've done:
Modify the setting for the project
<PropertyGroup>
<TargetFramework>netcoreapp2.1</TargetFramework>
<Platforms>AnyCPU;x64</Platforms>
<RuntimeFrameworkVersion>2.1.0</RuntimeFrameworkVersion>
<UseNETCoreGenerator>true</UseNETCoreGenerator>
<RazorCompileOnBuild>true</RazorCompileOnBuild>
</PropertyGroup>
I also added binding redirect in the web.config
<assemblyIdentity name="System.Runtime" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"
bindingRedirect oldVersion="0.0.0.0-4.2.0.0" newVersion="4.2.1.0"
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="System.Runtime" publicKeyToken="b03f5f7f11d50a3a" culture="neutral"/>
<bindingRedirect oldVersion="0.0.0.0-4.2.0.0" newVersion="4.2.1.0" />
</dependentAssembly>
</assemblyBinding>
Install .net core 2.1 on the server
I also deleted my .vs folder and close my visual studio and open it again.
Exception :
Microsoft.AspNetCore.Mvc.Razor.Compilation.CompilationFailedException: One or more compilation failures occurred:error CS1705: Assembly Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' uses 'System.Runtime, Version=4.2.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' which has a higher version than referenced assembly 'System.Runtime' with identity 'System.Runtime, Version=4.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'
I had same problem. When I added the Views folder from the solution to the publish folder then the problem went away. For some reason Razor requires these source files to be present in the server AND up-to-date even when it compiles them also into .dll. Therefore it is strange indeed that the Views folder is not automatically copied during publish.
I personally made a junction like this
junction "MyProject\bin\Release\netcoreapp2.1\linux-x64\publish\Views" "MyProject\Views"
Alternatively, disabling the following line might help (have not tested but this issue seems to be related since in earlier versions of Net.Core there was no Razor compilation).
<RazorCompileOnBuild>true</RazorCompileOnBuild>
to
<RazorCompileOnBuild>false</RazorCompileOnBuild>

dll versions displayed in visual studio .Net not reflecting the referenced dll file/product versions

I have a console app c# project that depends on NHibernate 3.3.2 and ShapArch.NHibernate 2.0.4.628 which has been compiled with NHibernate 3.3.1 (as far as I know - I might be wrong, but when I created a 2.0.4 SharpArch project it downloaded NH 3.3.1 via Nuget ).
Why does Visual Studio show NHibernate as being version 3.3.1.4000 when the referenced dll is 3.3.2.4000? The Specific Version property is set to false for all references. And the version for SharpArch appears in VS 2.0.0.0 instead of 2.0.4 which is the file/product version.
In the app config I have:
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="NHibernate" publicKeyToken="aa95f207798dfdb4" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-3.3.1.4000" newVersion="3.3.2.4000" />
</dependentAssembly>
</assemblyBinding>
</runtime>
The app fails to load with:
System.IO.FileLoadException was unhandled
Message=Could not load file or assembly 'NHibernate, Version=3.3.2.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)
Source=MyApp.ResourcesGenerator
FileName=NHibernate, Version=3.3.2.4000, Culture=neutral, PublicKeyToken=aa95f207798dfdb4
FusionLog=""
StackTrace:
at MyApp.ResourcesGenerator.Program.InitializeNHibernateSession()
at SharpArch.NHibernate.NHibernateInitializer.InitializeNHibernateOnce(Action initMethod) in d:\Builds\SharpArch2\Solutions\SharpArch.NHibernate\NHibernateInitializer.cs:line 54
at MyApp.ResourcesGenerator.Program.Initialize() in C:\projects\tc\Trunk\Source_LibsUpgrade\Applications\PerformanceManagement\MyApp.ResourcesGenerator\Program.cs:line 149
at MyApp.ResourcesGenerator.Program.Main(String[] args) in C:\projects\tc\Trunk\Source_LibsUpgrade\Applications\PerformanceManagement\MyApp.ResourcesGenerator\Program.cs:line 31
at System.AppDomain._nExecuteAssembly(RuntimeAssembly assembly, String[] args)
at Microsoft.VisualStudio.HostingProcess.HostProc.RunUsersAssembly()
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean ignoreSyncCtx)
at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)
at System.Threading.ThreadHelper.ThreadStart()
InnerException: System.IO.FileLoadException
Message=Could not load file or assembly 'NHibernate, Version=3.3.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)
FileName=NHibernate, Version=3.3.0.4000, Culture=neutral, PublicKeyToken=aa95f207798dfdb4
I am not even sure why it's trying to load 3.3.0.4000 when sharp architecture has been compiled with 3.3.1.
NHibernate 3.3.2.GA has a file version of 3.3.2.4000 but the assembly version is still 3.3.1.4000. This was done to allow an upgrade of NHibernate without needing binding redirects. All future minor version upgrades of NHibernate will also follow this pattern.
So the solution for you is just to remove the binding redirect.
The confusing part here is that the Windows Explorer only shows the file and product versions but Visual Studio only shows the assembly version.

Version conflict with Castle.Core when using White and NHibernate

I found an issue trying to add White functionality to our testing framework based on Selenium WebDriver. After adding all references to project, it compiles
without errors. But it throws an exception when using method
Application.GetWindow(windowTitle):
Application application = Application.Attach(processID);
Window downloadWindow = application.GetWindow(windowTitle);
ex.Message="Could not load file or assembly 'Castle.Core, Version=1.2.0.0, Culture=neutral, PublicKeyToken=407dd0808d44fbdc' or one of its dependencies.
The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)"
I downloaded latest version of Castle.Core but problem remains. So I remove references to the last version of Castle.Core and add references with NuGet to Castle.DynamicProxy
and Castle.Core 1.2.0 (this version I used for separate tests and they work). But with obsolete versions of Castle.Core there is an issue with NHibernate. It does not work.
Is there any decisions for such problem?
Maybe you can add an assembly binding in your web.config (or app.config) to forward the current version to return when resolving 1.2.0.0:
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="Castle.Core" publicKeyToken="407dd0808d44fbdc" />
<bindingRedirect oldVersion="1.2.0.0" newVersion="2.5.2.0" />
</dependentAssembly>
</assemblyBinding>
</runtime>
And hope that they are compatible. I'm not sure that the publicKeyToken is the same, that is the one from 1.2.0.0 so you should change that to reflect 2.5.2.0 I think, or if it wants the 1.2.0.0 token.

How to solve: Custom MSBuild task requires assembly outside of AppBase

I have a custom Task that I want to execute when building my C# projects. This task is located in MyTask.dll, which references another assembly, MyCommon.DLL.
The problem is that MyCommon.dll is located at "..\Common\MyCommon.dll" relative to MyTask.dll, which puts it outside the AppBase dir for MSBuild process. I've confirmed that this is indeed the problem by analyzing MSBuild's log and seeing Fusion's report about the binding failure.
What can I do to make Fusion find MyCommon.dll during the build process? Note that moving the assembly would break my app, which also depends on it.
UPDATE: Well, it seems I'll go with using a copy afterall. Other solutions all require system-wide modifications, which isn't really warranted here.
So copy it instead? Just a thought. Have a copy there just to support the build that you delete once you're done with it.
I see multiple solutions :
1st : Add the assembly in the GAC (your assembly must have a strong name)
gacutil /I <assembly name>
2nd : Locate the assembly through Codebases or Probing, in your machine.config file or in msbuild.exe.config .
<configuration>
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="MyCommon"
publicKeyToken="32ab4ba45e0a69a1"
culture="neutral" />
<codeBase version="2.0.0.0"
href="file://C:/yourpath/MyCommon.DLL"/>
</dependentAssembly>
</assemblyBinding>
</runtime>
</configuration>
3rd : copy the assembly in the same directory before and delete it after, like David M said.
All of these "solutions" create more dependencies which complicate the environment. There should be an easier way to update the probing path at runtime..
Specifically MSBuild should allow you to add probing paths in your .proj file, or to specify the dependant dlls
You can define a custom UsingTask:
<UsingTask TaskName="Task" AssemblyFile="Assembly.dll" />
but you cant add dependencies? it should be included... here with something like
<UsingTask TaskName="Task" AssemblyFile="Assembly.dll">
<DependantAssembly AssemblyFile="dependant.dll"/>
</UsingTask>
But, no this isn't supported...
An option is to use ILMerge to merge the dependency into the task assembly.