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
Related
ASP.NET Core 2.1
We have a shared dll, that is used in a few projects (via project reference)
We have class in that was named Proofer, and is now named ProofReader.
This was done through mass find and replace.
Nowhere in our source files locally exists any files containing the text Proofer.
VSTS builds the application without issue, then we send it via a release pipeline to Azure. All succeed.
Despite this we attempt to run the web app and get the following:
An unhandled exception occurred while processing the request.
TypeLoadException: Could not load type
'MainShared.Models.Proofer' from assembly 'MainShared,
Version=1.0.0.0, Culture=neutral, PublicKeyToken=null'.
System.Reflection.CustomAttribute._CreateCaObject(RuntimeModule
pModule, IRuntimeMethodInfo pCtor, Byte** ppBlob, Byte* pEndBlob,
Int32* pcNamedArgs)
We are having trouble determining if this is in the build, maybe something not being rebuilt when it should be, or something still cached on Azure that isn't being overwritten.
A few places I can suggest you look into -
If you are using app service web apps in azure , we can use the kudu (web app extension to remove/clean the files) to make sure you have a clean destination.
Check the VSTS Release logs if you have access to , it shows the files which are overwritten and the ones which could not be. Once i had a similar issue and found that the logs were already warning me that a few could not be overwritten.
If you are using VM's for your app deployment if has access to it , remove/backup the files under your site folder.
I had a similar problem after some redesign for a Web App using ASP.NET Core 2.2 (hosted on Azure), that some old not even anymore existing references causing the Load type exceptions to happen and the Web App simply refused to come up. I tried to clean everything up in Visual Studio, even deleted the bin and object directories, but the old reference was still looked for. In Kudu on the Azure portal I saw the *.PrecompiledViews.dll and *.PrecompiledViews.pdb files, which were very old. I simply removed them directly on the Azure server and could then simply start up my app and everything came up again. This fault should be fixed from the source. If I do a complete rebuild, I expect this old garbage to be taken care of during the publishing to the website. This is something that Microsoft should fix and as I can see this happened to others over half a year ago. Thanks Mark Johnson for your very useful hint about those files!
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 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.