I have an MVC4 web application running locally using Entity Framework 6. It is running as any CPU. When I deploy to Azure via web deploy the home page loads fine, but when I browse to a page that uses Entity Framework I see:
Could not load file or assembly 'EntityFramework, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' or one of its dependencies. The module was expected to contain an assembly manifest.
I have tried building / deploying as X64 and x86. I have tried changing the platform mode between 32 and 64 bit in the Azure configure tab. I have tried Integrated and Classic modes. I have tried removing the package and reinstalling via NuGet.
Additionally if I try to run locally as X64 then it gives:
Could not load file or assembly 'ProjectName' or one of its dependencies. An attempt was made to load a program with an incorrect format.
This means it fails on the first page, before even getting to the page that uses Entity Framework.
How do I fix being able to use Entity Framework on Azure websites?
I had this same problem. Using FTP I noticed some unneeded DLLs in my bin folder, so I deleted all the DLLs and republished. That fixed it!
Related
In my newly created BizTalk 2020 Dev environment when I'm adding a BizTalk Server Application Project (.btaproj) to the solution, the dialog window where you set the name of the project is showing the .NET framework selector and it defaults to version 4.7.2 as expected.
However when the project is added to the solution I can see in the properties for the project that it is targeting .NET 4.6.1. Has anyone seen this? is it a bug or something wrong with installation?
Naturally I change it to version 4.7.2 as the regular BizTalk project and everything compiles fine in Visual Studio.
But on our build server the same project fails. We use Azure Devops for CICD.On the build server we have the same version of VS installed (2019 enterprise) and BizTalk Server Extention (v3.12.1.0) is installed as well as msbuild tools from BizTalk server installation.
In the logs I first get a Warning:
C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\MSBuild\Current\Bin\Microsoft.Common.CurrentVersion.targets(2106,5): warning MSB3274: The primary reference "A.dll" could not be resolved because it was built against the ".NETFramework,Version=v4.7.2" framework. This is a higher version than the currently targeted framework ".NETFramework,Version=v4.6.1". [B.btaproj]*
And further down in the log the btaproj will not find the assemblies to include in the .zip package.
Message above implies that I have different target versions but I don't.
Now the strange thing is that I can log on to the build server and clone the same project and compile it with VS just fine.
The only way to make the build server compile the project successfully (or any other BizTalk project with .btaproj for that matter) is to change .NET to 4.6.1 (for both .btproj and .btaproj) and it all compiles nicely and deploys to BizTalk environment.
I have checked project files and files checked in to Git and everything seems OK with the sources files. The clean flag I set to clean sources and output directory. I Can compile a regular BizTalk project and .NET application with 4.7.2 on build server just fine it's only when I involve a .btaproj project where it starts to misbehave.
Can anyone point out where to start to look? the .btaproj seems fishy to begin with but it can also be isolated to the msbuild on build server and it differs from compiling with Visual Studio.
Since the BizTalk Server Application project e.g .btaproj defaults to target framework moniker 4.6.1 when added to the solution you will need to manually change the version manually for BOTH debug and release.
Do not get misled by the create project dialog where it defaults to version 4.7.2
As a workaround ,you can specify /p:TargetFrameworkVersion=v4.7.2 in the MSBuild Arguments column of the MSBuild task.
MSBuild lets you set properties on the command line by using the -property (or -p) switch. These global property values override property values that are set in the project file. This includes environment properties, but does not include reserved properties, which cannot be changed.
For details ,please refer to this document.
I've an asp.net core project with appsettings.json file being copied to the output directory on each build with following "copyToOutput" option in project.json file. When I build it and go to the build folder I can see it. But when I build a Service Fabric application that uses this asp.net core project as service, in package folder, appsettings.json file is missing. Are there any issues with processing content files for asp.net core?
Actually, the problem was related to the fact that there is being called dotnet publish step when creating ASF package. Hence "copyToOutput" was supposed to be done via "publishOptions".
Scenario:
I just upgraded all the projects in my solution to a new version of PostSharp (shouldn't matter the library, hopefully.) I have around 20 projects in my solution and around half of them originally referenced version 3.0.42 and I just updated them all to the latest version. My solution contains a web app that references projects within this solution, as well as some external dll references. It just so happens that some of those dll references also had dependencies on PostSharp version 3.0.42 and I'm now getting the typical "The located assembly's manifest definition does not match the assembly reference." error from those external dlls when trying to run my app. The web.config has the appropriate bindingdirect in place. Is there any way to have the bindingrediect impact my external dlls as well? Rebuilding them with the latest PostSharp dll is not currently an option.
I have my own assembly where I've embedded some third party assemblies into the dll via the Vitivec Assemblies Embedder extension. These third party assemblies are all used internally and not exposed outside of my assembly.
All works fine when running the assembly under asp.net scenario, however, in LINQPad, when I reference my dll in LINQPad, it gives me an 'assembly load/not found' error for the embedded assembly and I must include a reference the third party assembly as well (even though its usage is completely private within my assembly).
The error I get is:
Could not load file or assembly '{Assmebly.Namespace}, Version=7.1.2.136, Culture=neutral, PublicKeyToken=39c186f5904944ec' or one of its dependencies. The system cannot find the file specified.
Is LINQPad unable to work in this scenario? I'd like to share my assembly and LINQPad script with others without having to also distribute the third party assembly that is already embedded into my assembly.
I've installed .net 4 in the server.
Now I don't know if I must install the MVC 2 for VS2008 or what because I got this error:
Could not load file or assembly 'System.Web.Mvc, Version=2.0.0.0,
Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies.
The system cannot find the file specified.
VS 2010 comes with MVC 2, but it's not a part of the .NET Framework proper. This means that if you go download the .NET Framework 4 redistributable, it will not include the MVC 2 runtime.
But since MVC is bin-deployable, this is fine. Your application - when deployed to a .NET 3.5 SP1 or .NET 4 server - will just copy System.Web.Mvc.dll to its /bin folder, and everything will run as expected. MVC runs just fine in Medium Trust.
To do a server wide install you need to download AspNetMVC2_VS2008.exe from here, rename the .exe to .zip and inside the mvcruntime sub-folder you'll find the AspNetMVC2.msi file.
Then you have to run:
msiexec /i AspNetMVC2.msi /l*v .\mvc.log MVC_SERVER_INSTALL="YES"
by default the System.Web.Mvc.dll is not included when you compile an MVC 2 project;
you have to change the setting "Copy Local" to True on the Reference properties to get the file in your /bin