I was having performance issues with table storage and upgraded to the latest library/sdk. Everything works fine locally and I can run on the emulator. However, when I try to deploy to my Azure Cloud Service I get the following error:
Details: Recovering role... Unhandled Exception: Could not load file or assembly 'Microsoft.Azure.DocumentDB.Core, Version=2.11.2.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)
The web role just recycles constantly with this error. The actual dll version is 2.11.6.0. Things I have tried:
I have logged on to the web role and checked the dll is the expected one (2.11.6.0).
bindingRedirects: all relevant projects have a binding redirect of this form:
<dependentAssembly>
<assemblyIdentity name="Microsoft.Azure.DocumentDB.Core" publicKeyToken="31bf3856ad364e35" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-2.11.6.0" newVersion="2.11.6.0" />
</dependentAssembly>
I have done a text search through all files in my project for Microsoft.Azure.DocumentDB.Core - every reference (that mentions version) references 2.11.6.0. This includes files of this form dll.config file - which I did not manually edit but which do have the correct redirect.
I tried changing the Azure role osFamily to 6 (it had been 5)
I tried deleting the packages folder and regenerating
I tried deleting all redirect statements and allowing Visual Studio to automatically generate them for me.
The publish is done via 'publish' in Visual Studio 2019 on the Cloud Service (csdef).
Could anyone suggest what else I can try to deploy this cloud service?
Eventually found a way round this. So, when run locally a file WebRoleName.dll.config is produced alongside the web.config. This file is not deployed. The content is an exact copy of the web.config file. All its settings are ignored apart from the redirects. The redirects are used, seemingly, just while the web role is being started up. So, I added the file based on my local configuration (so completely the wrong database settings, etc.) to the root of my Web Role project and set it to Content - Copy Always.
Now everything runs OK - obviously it would be better if this generated file was deployed by the Visual Studio Azure publish automatically.
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 am having trouble getting migrations to run to create / update my Sql Db hosted on Azure. They run fine locally to my LocalDb but seem to be completely ignored when releasing to Azure.
Details:
- Asp.Net MVC 5.2.3
- Entity Framework 6.1.3
- Visual Studio Team Services (online)
- Azure Web App & Azure SQL Db (under Imagine / Dreamspark subscription)
I created a different application that didn't use CI, but used the Publish feature within Visual Studio and it published fine and worked. I have since removed that web app & db from Azure since the subscription only allows one db.
I'm thinking it may be something I'm missing in setting up the build definition in VSTS, I'm just not sure what.
I have tried:
https://blogs.msdn.microsoft.com/webdev/2014/04/08/ef-code-first-migrations-deployment-to-an-azure-cloud-service/ (this did nothing for me)
https://www.benday.com/2016/11/07/using-tfs-build-to-deploy-entity-framework-database-migrations-with-migrate-exe/ (I received a build error that I didn't have a release definition in my bin folder)
... as well as a bunch of others (I don't have the windows open any longer or I'd link them too).
My current build steps include:
NuGet restore - NuGet Installer
Build solution - Visual Studio Build
Test Assemblies - Visual Studio Test
Publish symbols path - Index Sources & Publish Symbols
Publish Artifact - Publish Build Artifacts
In my local env, EF works when I Enable-Migrations, Add-Migration, Update-Database. I'm guessing none of the above steps do this so I need one or more steps. Ben Day's blog seems like it should work, but for some reason, it's not finding my bin/release file.
The actual application deploys to Azure just fine upon release of the above successful build definition. It's just that the database is completely ignored. Using SSMS, I check the Azure db, and while it exists, it has none of my tables or data.
What am I missing?
Thanks.
**Edit - found the simple item I was missing. I need to add the connection string for the db to the web app in Azure. It now has my initial tables, and stores data using those tables, but doesn't pick up migrations. So something I've done in the last two days got my initial tables out there. Now.. to remember what it was.
**2nd Edit - So, I think the tables made it into the release db before I fixed my connection string in VSTS. One of the things I tried was creating a separate database project. I think when I pushed that at some point, the tables in existence at that time also pushed to release, I just couldn't see them because I hadn't connected the application and db together? At any rate, EF migrations are still not being recognized. I tried Ben Day's suggestion again, but I"m getting the build error:
Unhandled Exception: System.IO.FileNotFoundException: Could not load file or assembly 'EntityFramework, Version=6.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' or one of its dependencies. The system cannot find the file specified.
I am using EF 6.1.3
I ran into this as well. I was using Visual Studio to publish my Azure app service. After doing some research (https://learn.microsoft.com/en-us/aspnet/mvc/overview/getting-started/getting-started-with-ef-using-mvc/migrations-and-deployment-with-the-entity-framework-in-an-asp-net-mvc-application#deploy-to-azure), I came to learn that VS Publish transforms your web config when you check the box for "Update Database" in Publish setting, adding a connection string that refers to the database containing your _migrations table, as well as a "contexts" element under "entityFramework". You can see what a previous publish has done with your web.config by looking at "..obj\Release\InsertEFCodeFirstDeploy\transformed\web.config".
So to recreate this same action when using a build and release definition in VSTS, I added 2 XDT "insert" transforms in Web.Release.config in my service project. Mine looks like this:
<?xml version="1.0"?>
<!-- For more information on using Web.config transformation visit http://go.microsoft.com/fwlink/?LinkId=301874 -->
<configuration xmlns:xdt="http://schemas.microsoft.com/XML-Document-Transform">
<connectionStrings>
<add name="MS_TableConnectionString_DatabasePublish" connectionString="Data Source=(localdb)\MSSQLLocalDB;Initial Catalog=AzureStorageEmulatorDb45;Integrated Security=True;Connect Timeout=30;Encrypt=False;TrustServerCertificate=True"
providerName="System.Data.SqlClient" xdt:Transform="Insert" />
</connectionStrings>
<system.web>
<compilation xdt:Transform="RemoveAttributes(debug)" />
</system.web>
<entityFramework>
<contexts xdt:Transform="Insert">
<context type="helpmeshopService.Models.helpmeshopContext, helpmeshopService">
<databaseInitializer type="System.Data.Entity.MigrateDatabaseToLatestVersion`2[[helpmeshopService.Models.helpmeshopContext, helpmeshopService], [helpmeshopService.Migrations.Configuration, helpmeshopService]], EntityFramework, PublicKeyToken=b77a5c561934e089">
<parameters>
<parameter value="MS_TableConnectionString_DatabasePublish" />
</parameters>
</databaseInitializer>
</context>
</contexts>
</entityFramework>
</configuration>
Next, you will need to go to your App Service "Application Settings" in the Azure portal and add a connection string with name, "MS_TableConnectionString_DatabasePublish", and set its value to the same value as for "MS_TableConnectionString" that should already exist in your settings.
I have a well-established project that includes three worker roles. This project has always used F#, not in the worker roles themselves, but in the functions that they call. I've recently added another worker role to the project but the architecture (C# worker roles calling F# code) remains the same. Since these changes I've been getting these messages after deployment:
Could not load file or assembly 'FSharp.Core, Version=4.3.1.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The located assembly's manifest definition does not match the assembly reference.
This happens during Autofac dependency resolution:
Autofac.Core.DependencyResolutionException", "exceptionMessage": "An exception was thrown while invoking the constructor 'Void .ctor(Amazon.DynamoDBv2.AmazonDynamoDBConfig
I know this is a well known issue, and the solution is generally to add some binding redirects. I've added a redirect thus:
<dependentAssembly>
<assemblyIdentity name="FSharp.Core" publicKeyToken="b03f5f7f11d50a3a" culture="neutral" />
<bindingRedirect oldVersion="0.0.0.0-4.3.1.0" newVersion="4.3.1.0" />
...to every project in the solution that has an app.config, which includes all the worker roles. I've also verified that every reference to FSharp.core uses version 4.3.1.0 and has copy local set to true.
I've also tried adding FSharp.core to the C# projects in the solution via the FSharp.Core nuget package.
I'm not sure why you would need a BR here as it sounds to me like this was always working and just adding a new worker role has somehow botched things up.
Without knowing your deployment process, I would suggest firstly just performing a manual package of the Cloud Service (you can do this directly from within Visual Studio or the command line using cspack). This will give you a zip file which contains all the code that will be deployed into the worker role - make sure that this contains FSharp.Core (and the correct version).
I would also suggest doing a quick diff (if you're not already done so) with what has changed since you added the new worker role in.
Lastly - watch out with the FSharp.Core Nuget package - FSharp.Core is treated differently by Visual Studio and by default won't reference the Nuget version if there's already a version of FSharp.Core referenced in the project.
I have an MVC 5 web application that I'd prefer to save time with startup by pre-compiling on publication. However, when I choose "Precompile during publishing", I get the following Error:
Error 5082 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).
error ASPRUNTIME 0 0 USIS
The Web.Config Does have a binding redirect for this Reference
<dependentAssembly>
<assemblyIdentity name="DotNetOpenAuth.Core" publicKeyToken="2780CCD10D57B246" culture="neutral" />
<bindingRedirect oldVersion="1.0.0.0-4.1.0.0" newVersion="4.1.0.0" />
</dependentAssembly>
This builds and deploys fine if I do not have this precompile option checked, and the Web is working fine without issues. I just cannot publish with this precompile option checked.
I'd really like to have the website compile all views and etc only on publish, and never recompile in the live production site. Some Documentation I was looking at was suggesting this was the propose of these features... but I'm having no luck.
EDIT: I have had some success. I realized that I was purposely not deploying the Web.Config file such that a developer doesn't accidently harm the production environment configuration, but it appears that the precompile build was copying files to a temporary location, and without the Web.Config file being deployed, no Web.Config file was there, meaning no Dependency translations.
So, Now it looks like I'm going to have to deploy the Web.Config if I want to pre-compile (I had set its Build Action from "Content" to "None", and now I've set it back again.) This means I'm going to need to look into Web.Config Transformations, or etc.
Thanks,
Greg
The only thing precompilation does is compile the views. The fact that this happens only when precompilation is set means that there's something in one of your views that is generating this error. That's kind of irrelevant, though.
The best way I've found to correct this particular error is to uninstall and reinstall the offending Nuget package.
Just go into the Package Manager Console, make sure the project that generates the error is selected for "Default Project", and then run:
> Uninstall-Package DotNetOpenAuth.Core -Force
> Install-Package DotNetOpenAuth.Core
That should resolve the issue and allow your site to publish and run fine, with or without precompilation.
Solution:
It turns out that since I wasn't publishing the Web.config file, that the binding redirects were not being made. The solution was to change this file back to being published (Build Action from "None" to "Content"), and then the pre-compilation was succeeding.
For others with an MVC or ASP.NET web site that runs slow each time hitting a new page/view, I'd recommend giving this pre-compilation feature with publishing a try. It's just hidden under file options in the publication settings (VS 2012.) I chose to Precompile, and to make the site not-updatable to avoid the dynamic view/page compilations. See for more information: What effect does the new precompile during publishing option have on MVC4 applications? .
Also, to push the correct settings and connection strings to Live and Test I started using the Translation Templates "Web.Release.config" and "Web.Debug.config". These will swap out Web.config lines when deploying only. See http://go.microsoft.com/fwlink/?LinkId=125889 for more information.
I have a workflow project in my solution that referenced Microsoft.Activies.Extensions.dll 2.0.2.16
I used the NuGet Package Manager to upgrade to the current version 2.0.6.9
Deploying the web role that references the workflow project .dll to the cloud I get:
Could not load file or assembly 'Microsoft.Activities.Extensions, PublicKeyToken=23b0c89d0d5ad43f' or one of its dependencies. The system cannot find the file specified.
I remote desktoped to the VM and checked the F:/approot/bin to see that neither version of the assembly was deployed.
Since this a NuGet package I can find it in my <Solution root>/Packages folder. I see the new folder created by NuGet but also the old version folder that was left behind although the assembly was not inside. I deleted that folder and put an assembly redirect in my web.config:
<dependentAssembly>
<assemblyIdentity name="Microsoft.Activities.Extensions" publicKeyToken="23b0c89d0d5ad43f" />
<bindingRedirect oldVersion="2.0.2.12" newVersion="2.0.6.9" />
</dependentAssembly>
Clead, build, re-deploy via Publish.
The error persists, and digging into the approot/bin again shows that the assembly was still not deployed.
I, of course, have Copy Local set to true.
Why is it not getting deployed?
Ok, resolved from finding this article:
http://weblogs.asp.net/albertpascual/archive/2008/12/16/the-cloud-for-a-fast-deployment-of-proof-of-concepts.aspx
Turns out when a web-role references an assembly than in turn references other assemblies, those assemblies will not be deployed even if Copy Local = true.
The solution is to references those child dependencies directly in the web-role project with Copy Local to true.
Only then did they show up in my approot/bin upon deployment.