After upgrading to ServiceStack v3.9.70 via nuGet from v3.9.43, I noticed that the ServiceStack.Interfaces.dll is no longer copied over to projects that depend on the class library using ServiceStack. This causes the following error:
System.IO.FileNotFoundException: Could not load file or assembly 'ServiceStack.Interfaces, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.
File name: 'ServiceStack.Interfaces, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'
All other ServiceStack dlls are copied, only ServiceStack.Interfaces is missing. All references are set to Copy Local = True, and this StackOverflow post's suggestion does not solve the problem.
I noticed that ServiceStack.Interfaces.dll is the only one with a version of 1.0.0.0, all others are set to 3.9.70.0. Could this be a cause?
Does anyone know how to fix it without manually referencing ServiceStack.Interfaces.dll in cascade in all projects referencing my class library?
Update - 2014-03-06
Problem still exists with v3.9.71.0. It really is related to the fact that the ServiceStack.Interfaces assembly has its version left to 1.0.0.0 instead of being.
I cloned the github repository for ServiceStack and changed this line in the build\build.proj file and ran build\build.bat.
<!-- Exclude versioning future strong-named libs -->
<RegexTransform Include="$(BuildSolutionDir)/src/**/AssemblyInfo.cs"
Exclude="$(SrcDir)/ServiceStack.Interfaces*/Properties/AssemblyInfo.cs">
<Find>\d+\.\d+\.\d+\.\d+</Find>
<ReplaceWith>$(Version)</ReplaceWith>
</RegexTransform>
for this (noticed the removed exclusion)
<RegexTransform Include="$(BuildSolutionDir)/src/**/AssemblyInfo.cs">
<Find>\d+\.\d+\.\d+\.\d+</Find>
<ReplaceWith>$(Version)</ReplaceWith>
</RegexTransform>
Result: Now it works correctly, i.e. the file ServiceStack.Interfaces.dll is copied over to projects referencing a project that references ServiceStack.
Can someone explains this to me? Why would you want to exclude the Interfaces from versionning?
The assembly versions were intentionally changed from 3.9.* to 1.0.0.0 when the v4 was released.
It probably was due to v4 ServiceStack.Interfaces.dll being changed to being strong-named and versioned 4.0. The 'bsd' 3.9.* version was rolled back to 1.0, probably to be clearly the oldest possible.
More detail in noted in this SO answer.
Related
I have a strange issue.
When I publish my MVC site to Azure it works.
When I hook it up to deploy using continuous integration on check-in I get a missing dll:
Could not load file or assembly 'Microsoft.Owin, Version=2.1.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
I can't work out what is going on as the code base is always the same!
All, after reading a couple of comments I have uploaded the following images. All my Owin references are coming from Nuget but it looks like I have a few different version numbers of Own references. I don't know why this would be as the web project.
I have searched my project for the word Owin and found there are very few references and, as you can see in this image, there are 3 different version numbers for various DLLs that are related to Owin:
Also, here are all the references to Owin in my Visual Studio Online build log:
Maybe someone can comment on why there are varying version?
thanks
Russ
Summary: I have ONE project in a solution that I can't point to WebPages 3.0 (or Helpers 3.0). The others are fine, but one just immediately resolves to the Program Files x86 2.0 assembly.
Background: I have an MVC app that I inherited. I've done a few updates to it, bringing it up to MVC-3 in the last iteration. To cut to the chase, I've found myself in an unexpected bind that's seemed to snowball through my attempted fixes.
I always strive for binary deployments, eliminating the need to install packages on the build server and the web servers. Therefore, I had MVC/ASP.Net WePage binaries in the solution tree with references to those local copies.
What I've changed: Believe it or not, I've never messed with NU GET, and decided to give it a whirl. I removed all my local binaries (2x, 3x, 100x checked to make sure) and added MVC 5 and its dependencies. This seems great because I can eliminate my home-grown binary pattern in favor of the packages that are stored under the solution tree on disk/TFS. I also figured I might as well point all projects to the latest 4.5 FW.
Problems: On compilation VS is complaining that I have v2 and v3 of the mentioned DLL, but I have no references to v2. Also, before even compiling, if I remove the reference and re-add it (pointing to the package lib content) it immediately comes in as v2.0 and the resolved folder is the x86 v2 instance.
While trying to resolve this I've removed the packages and reinstalled them several times to no avail.
I've also tried adding a binding redirect to we.config, but I suspect that's a runtime thing? I have a number of other projects in this solution, all of which are fine, pointing to 3.0!
I've used reflector to look at the references for all the assemblies in the bin folder, thinking I'd find something pointing to pages 2.0, but I don't.
Looking in the csproj file I see the version hard-coded to 2.0 in the Include. I changed it to 3.0 and when I reload the solution it's reverted to 2.0. Argh!
I've closed and reloaded the solution a hundred times. I've cleaned it 1,000 times. I've manually removed the obj/bin folders multiple times.
I just don't know how else to debug this!
<dependentAssembly>
<assemblyIdentity name="System.Web.WebPages" publicKeyToken="31bf3856ad364e35" />
<bindingRedirect oldVersion="0.0.0.0-3.0.0.0" newVersion="3.0.0.0" />
</dependentAssembly
<Reference Include="System.Web.Helpers, Version=3.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=MSIL">
<Private>True</Private>
<HintPath>..\..\packages\Microsoft.AspNet.WebPages.3.0.0\lib\net45\System.Web.Helpers.dll</HintPath>
</Reference>
I found a second Include in the csproj for WebPages and Helpers! I have no idea how they got there. Uninstalling the NUGET packages would remove the FIRST reference, but not the second. To add to the frustration the second reference specified no version or location. Adding a version and location specific reference (NUGET or manually) would be overridden immediately with the GAC version!
I'm getting a run time exception in my deployed, exported, and then imported to another box... CRM Solution. The Exception is:
System.TypeLoadException: Could not load type 'System.Runtime.CompilerServices.ExtensionAttribute' from assembly 'mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089'
It only occurs when I use a MSBUILD script to do this. When I use VS (2010) by hand to do this, all is well. So, first suspect is my script. My script uses a MSBUILD custom task, inspired by http://fczaja.blogspot.com/2012/07/continuous-integration-with-crm.html.
My sense is the issue could be on the Export step - which uses the Microsoft.Xrm.Sdk.Client.OrganizationServiceProxy, up-cast to IOrganizationService.Execute, passing an ExportSolutionRequest object. We set the SolutionName and Managed properties only. Perhaps we're missing another property?
I'm trying to narrow it's root cause.
Are you by any chance using ILMerge on your plugin assembly?
If so I suspect it is an issue with your reference assemblies, perhaps having .NET 4.5 on the build server but not on the machine where you build it manually.
These links will explain futher if this is indeed the case:
http://www.mattwrock.com/post/2012/02/29/What-you-should-know-about-running-ILMerge-on-Net-45-Beta-assemblies-targeting-Net-40.aspx
The fundamental fix is to change your ILMerge reference assemblies to be -/targetplatform:"v4,C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework.NETFramework\v4.0"
I'm trying to use Windows Azure Caching Preview.
I have one dedicated cache worker role, One webrole that use the former cache, and one worker role that continuously update cache.
I followed the instructions on the Windows Azure guide but I still get an error :
Could not load file or assembly 'Microsoft.ApplicationServer.Caching.Core, Version=1.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
I double triple 1000000 checked dependencies, there are correct.
I noticed there were two sets of dlls : the ones version 1.0.0.0 I want to use, and another version 101.0.0.0 I don't want.
I added BindingRedirect statement to all my .config files to map 101 versions to 1.0.0.0
I checked the \bin folder, decompiled the dlls with Jetbrains, they are correct.
I begin to lose patience. Why doesn't .NET take the DLL I specify when I put the explicit path ?
Ok I found another way :
I just renamed C:\Program Files\Microsoft SDKs\Windows Azure.NET SDK\2012-06\ref\Microsoft.ApplicationServer.Caching.Core.dll to Microsoft.ApplicationServer.Caching.Core.dll_old.
It was enought for me.
Here is a more specific description of th issue : it seems to work perfectly when taking projects individually : I have 3 worker roles and one web role.
Each time I build my project one by one, I see the correct dll in output directory, I only have a problem with Windows Azure Cloud package, it seems to ignore the BindingRedirect directive.
AppFabric isn't setup to register its own DLLs after install.
You have to manually register them.
Run this in powershell to fix everything:
Set-location "C:\Program Files\AppFabric 1.1 for Windows Server"
[System.Reflection.Assembly]::Load("System.EnterpriseServices, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a")
$publish = New-Object System.EnterpriseServices.Internal.Publish
$publish.GacInstall("C:\Program Files\AppFabric 1.1 for Windows Server\Microsoft.ApplicationServer.Caching.Core.dll")
$publish.GacInstall("C:\Program Files\AppFabric 1.1 for Windows Server\Microsoft.ApplicationServer.Caching.Client.dll")
$publish.GacInstall("C:\Program Files\AppFabric 1.1 for Windows Server\Microsoft.WindowsFabric.Common.dll")
$publish.GacInstall("C:\Program Files\AppFabric 1.1 for Windows Server\Microsoft.WindowsFabric.Data.Common.dll")
iisreset
Just a suggestion to store in relevant place.
I have encountered with the problem described in the questiuon, only difference is that it could not find Caching.Client instead of Caching.Core. I tried removing libraries in SDK ref folder, as suggested in previous answer, but it did not help.
Anyway, my solution seems to be rather particular.
What helped in my case is that I found some libraries that were not referenced, but they were found among packages in the only environment where my project worked. Here they are:
* System.Web.Providers.1.1
* System.Web.Providers.Core.1.0
They were missed in packages.config file for some reason, so they could not be renewed from nuget feed.
So you might try referencing them directly or other way to make them accessible to the project you're trying to run.
In Microsoft Dynamics CRM 2011, I wrote one plug-in in C# for Account entity to do some operations on fields when Account record is created. In C# code I created my own custom assembly called My.Custom.Assembly.dll. Which contains some generic methods those I can use often in my plug-in. And I using this My.Custom.Assembly.dll and also added in reference in my project. Project builds successfully and plug-in registration also. The problem I faced when I was creating a Account record. Its throwing an error: "Could not load file or assembly My.Custom.Assembly.dll, Version=1.0.0.0 Culture=neutral, PublicKeyToken=def751c98b41d765 or one of its dependencies.The System cannot find the file specified." I got to know the problem is with My.Custom.Assembly.dll. Can you please help me to solve this problem..?
Your custom assembly cannot be loaded during the execution of your plugin.
Either install it in the GAC or merge it with your plugin assembly.
See my answer at Plugin with references not working on CRM 2011
A good place to start debugging this type of issue is to use Fusion Log Viewer to see the details of how .Net runtime is attempting to load the assembly. http://msdn.microsoft.com/en-us/library/e74a18c4(v=VS.100).aspx
Based on what you find in the log post more details if you need additional assitance.
You may also want to read up on How .net loads Assemblies