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.
Related
I have a web app on Azure. When I publish an update to it using WebDeply it doesn't work. I get a 502.5 Process Failure error. Upon investigation the content of the error is:
Unhandled Exception: System.IO.FileLoadException: Could not load file or assembly 'Microsoft.AspNetCore.Hosting.Abstractions, Version=2.0.2.0, Culture=neutral, PublicKeyToken=adb9793829ddae60'. The located assembly's manifest definition does not match the assembly reference. (Exception from HRESULT: 0x80131040)
at Web.Program.Main(String[] args)
Does anyone know why I would be getting this?
It works locally but not when published. The most recent update I did to the AspNetCore ddls was done as part of this release where I upgraded the NuGet packages reference to be the latest patch fixes ie. from 2.0.0 to 2.0.2. Is it something I did wrong?
I eventually solved the issue by using an FTP, deleting all of the DLLs in the website folder and re-publishing the application.
Seems Web Publish or VS decided not to update those files for some reason.
Addional information for Adam Stapleton.
As Adam Stapleton mentioned it seems that Web publish or VS doesn't update the related files. If we update the AspNetCore, I recommend that we could remove the Azure WebApp files during republish the WebApp. We also could do this with VS. For more detail information, please refer to the screenshot.
I add licensed select.pdf.dll to my SharePoint project. This dll file has added in both the visual studio reference and the package section(Deploy target as 'Global Assembly Cache (GAC)').
I was not able to deploy my solution to my sharepoint development server, with the error message
“Error occurred in deployment step 'Add Solution': Error: Cannot add the specified assembly to the global assembly cache: Select.Pdf.dll.”
I have googled the problem, someone cannot deploy because the .dll they want to deploy already existed in %windir%\assembly folder and the .dll is locked by other process.
VS2015 build error: Cannot add the specified assembly to the global assembly cache
https://devramblings.wordpress.com/2011/03/23/error-cannot-add-the-specified-assembly-to-the-global-assembly-cache/
However, the "Select.Pdf.dll" I want to deploy has never been deployed before, the %windir%\assembly and %windir%\Microsoft.Net\assembly folders do not have same name dll. file in them.
I have tried to restart VS, and reset IIS. the problem still existed.
Is there any way to solve the problem? Thank you.
You need to add the relevant .dep files also. When you add your assembly to the advanced section of the package you can add Class Resources at the bottom of the dialog. In my case I had to add Select.Tools.dep and Select.Html.dep before I could deploy my sharepoint solution.
#Mundi's answer works, only clarification is that for us, only selecting Select.Html.dep was enough. It is to be noted that you have to specify that you want to view all files (not just .dll) when selecting the additional Class Resources.
Alternative solution that worked for development scenario (but not advisable for production) is using appropriate gacutil.exe to your .net version.
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
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 have a app fabric service that I want to test. (http://xxx.cloudapp.net:8081/service.svc).
I created a console app and added a service reference to the service and got the following error:
Could not load file or assembly
'Microsoft.ServiceBus,
Version=1.0.0.0, Culture=neutral,
PublicKeyToken=31bf3856ad364e35' or
one of its dependencies. The system
cannot find the file specified.
I added a reference to Microsoft.ServiceBus from C:\Program Files (x86)\Windows Azure platform AppFabric SDK\V1.0\Assemblies\NET4.0
I set all assemblies in my project to Copy Local = True, as suggested here:
http://msdn.microsoft.com/en-us/library/ee706702.aspx
Additional Due diligence:
I opened Microsoft.ServiceBus in red-gate's reflector and confirmed that it is the correct version. Just for kicks, I also added references to each assembly referenced in reflector and set all references to copy local = true.
Any other ideas?
…Peter
Make sure you change the Target Framework (Project properties/Application tab) from '.NET Framework 4 Client Profile' to '.NET Framework 4'.
I found a similar post and that was what helped me.
I believe it has to with the fact that Microsoft.ServiceBus is not supported by the client profile of .NET 4.
When you reference Microsoft.ServiceBus.dll, reference it from the install location, e.g.,
C:\Program Files (x86)\Windows Azure
platform AppFabric
SDK\V1.0\Assemblies\NET4.0\Microsoft.ServiceBus.dll
... not from the GAC, and set Copy Local to true.
You need to do this in whatever you are deploying into Azure; the Microsoft.ServiceBus.dll needs to packaged with your project because it is not available by default in Azure.
If you fire up Fiddler, you see a 500 error when calling the service. This proves that the exception isn't in your calling application.
ServiceBus dll is not installed on Azure boxes
Make sure your reference to the assembly specifies COPY LOCAL
Also make sure you don’t have references to the service bus dll in upper projects which do NOT copy local (this might be your problem if you have verified 1 above)
You can check the CSX tree for your azure build folder to see if the assembly is being copied into the final package. That’s a lot quicker than uploading to azure or starting the dev fabric.
That should solve your problem