Hello I am trying to deploy asp.net MVC 4 project on azure
but I get this problem. I searched a lot about the solution but it looks like none
suit my case, this is the Error message I get :
Could not load file or assembly 'DotNetOpenAuth.Core, Version=4.0.0.0,
Culture=neutral, PublicKeyToken=2780ccd10d57b246' or one of its
dependencies. The located assembly's manifest definition does not
match the assembly reference. (Exception from HRESULT: 0x80131040)
Before the dotnetopenAuth have no reference in my project I downloaded
but still get the same error .
Anyone have an idea?
I know this is old, but I came across a similar problem and this question popped up as the closest case. This was my issue:
http://developers.de/blogs/damir_dobric/archive/2013/09/26/windows-azure-websites-error-could-not-load-file-or-assembly-dotnetopenauth-core.aspx
Being, a previous MVC project had been deployed, which contained these references. I deleted them by downloading the publish profile, and, with the "Remove additional files at destination" option checked, I published to Azure.
While publishing, you can select "Remove additional files at destination" and then publish again.
I ran into this issue with continuous deploy between visual studio online and azure.
I modified my build file and changed the "Do Not Delete" setting under "Deployment" in the "Process" Tab to False.
Good to go.
This is a case of version mismatch. The error itself says that manifest definition does not match.
Look carefully at the version of the referenced assembly and the version shown in error message.
In case you are not using openauth you can remove it's reference all together.
Related
I am using TFS 2010 and VS 2012.
I failed in my attempt to upgrade MVC4 to MVC5. I thought I rolled back my project OK in TFS but my builds fail because the references to EF version 6 have not all been removed.
As far as I can tell I have removed EF v6 everywhere in my code. However in my build I have the following message;
Unified primary reference "EntityFramework, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089".
Using this version instead of original version "4.4.0.0" in "C:\Builds\3\solutionA\solutionA- Test\Sources\projectB\projectB\bin\Debug\projectB.dll" because AutoUnify is 'true'.
Resolved file path is "C:\Builds\3\solutionA\solutionA - Test\Sources\MVC4\solutionA\solutionA.Model\lib\EntityFramework.dll".
Reference found at search path location "{CandidateAssemblyFiles}".
So what does "AutoUnify is true" mean?
Decided to make a proper answer from our comments. I think this initial problem was an out of sync dll, from the packages folder. You re-installed EF 5 fresh were still having packages issues.
This appears to also be something with your Nuget setup. This SO article is the same error as your latest build error. Build cannot find entity framework .
In particular this article from the accepted answer sounds very similar to the issues you're having. http://msmvps.com/blogs/rfennell/archive/2011/10/17/using-nuget-and-tfs-build-2010.aspx especially to your point that it works locally, but not in the build process. Let me know if your issues seems different.
I moved a web application I am working on from one machine to another. It is built using .Net MVC and Entity Framework but when I execute the Update-Database command so that the database is updated, I get this error:
Could not find any resources appropriate for the specified culture or the neutral culture. Make sure "NameofMigration.resources" was correctly embedded or linked into assembly "NameofProject" at compile time, or that all the satellite assemblies required are loadable and fully signed.
Does anyone know how to fix this error?
I had a similar issue when the resx part of the migration was not included in the project file when a fellow developer checked the project in (probably due to a merge issue). You may find that the resx file is there but greyed out. If it's there, try right clicking the "NameofMigration.resx" file and selecting "include in project". If it's not there, you better go find it on the other machine and add it to the project :-)
I think the issue (one issue) is that the .resx file is added as "dependent upon" (nested under) the .cs file, and the way the build engine works, "dependent upon" changes the name that an embedded resource is saved with (something like, it changes from being based on the filename to being based on the type name; I've dealt with this in other scenarios but can't remember for sure).
This leads to problems when using SDK .csproj files, for some reason (I guess that by default SDK .csproj does not change the resource name in this situation, but the migrations system expects it to).
As someone else had posted, SDK .csproj can use the following tag to change the embedded resource naming scheme for "dependent upon" resources, which then allows the migrations system to find the embedded resource:
<EmbeddedResourceUseDependentUponConvention>
true
</EmbeddedResourceUseDependentUponConvention>
This should go in a <PropertyGroup> of your SDK .csproj file.
For VS 2017, the solution is as follows:
Go to the project file, and for all of the migrations, apply the following format:
<Compile Include="Migrations\201804251606403_emailsWithEffort.cs" />
<Compile Include="Migrations\201804251606403_emailsWithEffort.Designer.cs">
<DependentUpon>201804251606403_emailsWithEffort.cs</DependentUpon>
</Compile>
<EmbeddedResource Include="Migrations\201804251606403_emailsWithEffort.resx">
<DependentUpon>201804251606403_emailsWithEffort.cs</DependentUpon>
</EmbeddedResource>
I guess that the problem is when changing version(s) of Visual Studio, old format of describing dependencies stays, and the Visual Studio 2017 can not interpret it correctly.
Hence, applying the format as described above (change your format to this), you can make the Visual Studio get the idea of where it's resources are.
Slightly different situation, where I created a new environment, and database, and received the above error message.
For my fix, I had to right-click on the migration files (initial and resx) and set property to embedded as resource. Update-database command ran fine afterward.
I encountered the same issue (VS 2017) and none of the solutions provided here worked. I fixed the problem by cleaning the solution and manually deleting the bin folder and then building it again.
If anybody wants to look into the source or compiler to know why this is happening; I don't feel like it right now. After an hour of tinkering, my resolution is odd.
Granted, I shouldn't have done this in the first place, but for quick code I temporarily added classes into the same file as my generated DbMigration 201906212110305_initial.cs. The mere existence of those temporary classes in the same file caused this error. As soon as I moved them to their own file (which I was going to do all along anyway) the runtime error vanished.
Unloading and then reloading migration file worked for me!
I downloaded the TFSBranchTool VS Extension Project.
Rebuilt and Installed, but when I try to apply Initial Structure I get the following Error:
Exection Error:
Exection of Action 'ConnectSourceControl' Failed. Details: Could not load file or assembly Microsoft.AlLMRangers.BranchTool.SourceControlWrapper......
Any idea what might be causing the problem ? I tried on 2 different Servers! , I got the latest Update of VS2012.
I got VS2012 SDK installed and Vs2012 ObjectModel too, not sure what I'm missing!
We have posted an update to the sample code on http://vsarguidance.codeplex.com/releases/view/96222, which addresses this bug.
The issue was that Microsoft.ALMRangers.BranchTool.SourceControlWrapper.dll was missed in VSIX package. As action execution engine using MEF to load actions, it has no direct references to actions implementation assembly.
Vladimir from the team fixed the issue by specifying assembly as the MEF asset in the VS extension’s manifest file. Now it’s redistributed inside the extension package.
Can you verify that you have the file Microsoft.ALMRangers.BranchTool.SourceControlWrapper.dll
in the following folder:
%LOCALAPPDATA%\Microsoft\VisualStudio\11.0\Extensions\Microsoft. ALM Rangers\TfsBranchToolVSExtension\1.0
If its not there - try deleting the TfsBranchToolVSExtension and re-install the VSIX.
I'm trying to publish a web site.
The publication works perfectly, but when I try to access the address it returns me the following error:
Parser Error Message: Could not load
file or assembly
'Microsoft.Web.Helpers' or one of its
dependencies. This assembly is built
by a runtime newer than the currently
loaded runtime and cannot be loaded.
Source Error:
Line 293:
Line 294:
Line 295: Line 296:
Line
297:
Source File:
C:\Windows\Microsoft.NET\Framework\v2.0.50727\Config\web.config
Line: 295
Assembly Load Trace: The following
information can be helpful to
determine why the assembly
'Microsoft.Web.Helpers' could not be
loaded.
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].
This does not happen when I'm running on the local site.
The application was developed and Sql Server WebMatrix Compac 4
If you read the error message it says "Could not load file or assembly 'Microsoft.Web.Helpers' or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded." If you then look at the version of the ASP.NET that this site is attempting to run under, it is ASP.NET Version:2.0.50727.4209.
Web Pages and the Web Helpers library need Version 4.0. Make sure the site targets the correct version of ASP.NET.
For missing assemblies a simple solution is to just bundle them with your project.
Go to your project -> references -> find this microsoft web helpers ref -> open the properties panel and set Copy Local to True
Edit: Also try setting assembly binding logging.
I suspect that your web.config is fine and that there is an assembly missing from your deployment.
You probably have to include microsoft.web.helpers in your deployment package or simply copy it to the bin folder.
You might find that there are other assemblies missing but you should be able to pick them off one by one.
There is a previous question Hosting WebMatrix Page
that lists all of the dlls you have to deploy and also suggests using Webdeploy
I have an ASP.NET MVC 2 application.
Web project contains a reference to SomeProject
SomeProject contains references to ExternalAssembly1 and ExternalAssembly2.
SomeProject explicitly calls into ExternalAssembly1, but NOT ExternalAssembly2.
ExternalAssembly1 calls into ExternalAssembly2
When I perform a local build everything is cool. All DLLs are included in the bin\debug folder. The problem is that when I use the Publish Web command in Visual Studio 2010, it deploys everything except ExternalAssembly2.
It appears to ignore assemblies that aren't directly used (remember, ExternalAssembly2 is only used by ExternalAssembly1).
Is there any way I can tell Visual Studio 2010 to include ExternalAssembly2?
I can write a dummy method that calls into ExternalAssembly2. This does work, but I really don't want to have dummy code for the sole purpose of causing VS2010 to publish the DLL.
None of these answers are sufficient in my mind. This does seem to be a genuine bug. I will update this response if I ever find a non-hack solution, or Microsoft fixes the bug.
Update:
Doesn't seem promising.
https://connect.microsoft.com/VisualStudio/feedback/details/731303/publish-web-feature-not-including-all-dlls
I am having this same problem (different assemblies though). If I reference the assemblies in my web project, then they will get included in the publish output, but they should be included anyway because they are indirect dependencies:
Web Project ---> Assembly A ---> Assembly B
On build, assemblies A and B are outputed to the \bin folder. On publish, only assembly A is outputed to the publish folder.
I have tried changing the publish settings to include all files in the web project, but then I have files in my publish output that shouldn't be deployed.
This seems like a bug to me.
I had the same problem with VS2010 and a WCF Service Application.
It turns out that if your (directly or indirectly) referenced DLL's are deployed to GAC, the VS publishing feature excludes them. Once I removed the assemblies from GAC, publishing feature started working as expected.
I guess VS is assuming that if your assemblies can be located in GAC on the machine you build, they will be located in GAC on the target machine as well. At least in my case this assumption is false.
My tests show that the external assemblies get published when I have a reference on them in the web project. I do not have to write any dummy code to make it work. This seems acceptable to me.
I agree with Nicholas that this seems to be a bug in visual studio. At least it escapes me what the reason for the behavior could be.
I have created this issue as a bug on Microsoft Connect. If anyone experiencing it could vote it up https://connect.microsoft.com/VisualStudio/feedback/details/637071/publish-web-feature-not-including-all-dlls then hopefully we'll get something done about it.
If you go into the ExternalAssembly2 reference property list and change the "Copy Local" to "True" i think that might solve your issue.
I don't know if you are watching this still but I found the solution (I had the exact same issue) via this MSDN article. Under "build action" for the file choose "Content" that should include it in the list of files publish brings over.
I have created a new Connect bug here https://connect.microsoft.com/VisualStudio/feedback/details/731303/publish-web-feature-not-including-all-dlls
I've also attached a solution and detailed steps to reproduce this issue. Lets hope this time they won't close it as Can't Reproduce.
Vote for this connect issue if you experience the missing dll problem.
Copy local did the trick. I had an issue that the Newtonsoft.Json assembly get included in the deploymeny package. Copy local was set to false.
I am experiencing the same type of issue with a web project. I have a web project that references assembly A which references assembly B. It worked fine for some time but today it was broken. I did a rebuild of the solution and this time it deployed everything correctly.
I had this same problem today. I published my web project and realized that not all of the reference DLL's were there. In particular, the indirect DLL references.
It turns out that the directory in which I was publishing to was out of disk space (network share). I had just enough space to publish all the files except for few indirect reference DLL's. The sad part is that VS08 didn't throw any errors. It just published the files are usual. I cleared out some HDD space and everything worked fine.
I didn't find the HDD space issue until I tried to manually move the DLL's over.
in my case it is quite tricky.
Reference to ExternalAssembly2 is not required to Build the project but vital for run-time since we use reflection to configure Unity container.
So, I delete the reference - build the project successfully, but get run-time error.
If I preserve the reference I can Build and Run the application but I cannot Publish it with ExternalAssembly2 - get run-time exception as well.
This is happen because of internal VS2010 assemblies optimization.
So, what we can do here?
1. Put some unrequired peice of code to use any ExternalAssembly2's class.
2. escape from reflection and use static assemblies linking.
Hope this helps to smbd.
I got the same problem and this is a VS2010 bug if there's a reference link like:
Web Project --> custom project --> assembly1 -->(indirectly) assembly2.
For now I find if I reference the Assembly1 in the web project, then assembly2 is included in the bin folder.
So I had to add an additional reference link like:
Web project --> assembly1 -->(indirectly) assembly2.
Then VS can recognize assembly2 and include its dll file in publish action.