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!
Related
PS: Found solution see below
i deployed my API to azure via bitbucket pipleine using FTP, but whehn i open the link of the API it displays "HTTP Error 500.30 - ASP.NET Core app failed to start"
Also when i make a request over postman or the frontend SPA it gives me ther same error.
Im realy lost within azure, becouse so many menus and i cant understand whats the problem. It works fine locally and the pipeline was sucessfully.
Can someone help me understand whats going on?
PS: after some diagnostic ( its menu is not intuitive at all) i found this:
: System.IO.FileNotFoundException: Could not load file or assembly 'Newtonsoft.Json, Version=12.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed'. The system cannot find the file specified. File name: 'Newtonsoft.Json, Version=12.0.0.0, Culture=neutral, PublicKeyToken=30ad4fe6b2a6aeed'
My instaled verson is 12.0.0.3 and version 12.0.0.0 dosent even exist on nuget packet manager. Any ideas?
PS: FOUND A SOLUTION
my pipeline is:
https://ibb.co/xC1tcFp
Before the solution the line " cp ./AzureFix/Newtonsoft.Json.dll ./publish" didnt existed and the problem was that the file "Newtonsoft.Json.dll" that bitbucket generated inside the "publish" folder was invalid and when i did "dotnet publish --output publish --configuration release" in my pc that same file was valid.
I found that by using an FTP software to transfer my local files of the "publish" folder to azure and it worked.
So i created a folder in the bitbucket repository with the valid file inside it and in the pipeline i added a line that copy that file to the "publish" folder generated by bitbucket folder and it works like a charm.
Why did that happen ( the generated file of the bitbucket "publish" was invalid) ?
500.30 errors are startup problems, and can stem from a lot of different things, so giving an exact answer is tough. Check your Startup.cs and Program.cs to ensure everything is correct. This could be various dependencies such as DB stuff, cache, KeyVault, etc. or issues with ASP.Net versions.
If you have App Insights running for this App Service, check to see if it reports any issues. Or turn on application logging (https://learn.microsoft.com/en-us/azure/app-service/troubleshoot-diagnostic-logs).
You can also use Kudo to do advanced debugging: https://zimmergren.net/solving-asp-net-core-3-on-azure-app-service-causing-500-30-in-process-startup-failure/
Please check if all the NuGet packages are updated -
I struggled with this error for four days and tried every possible suggestion on forum.
And finally after updating all NuGet packages the problem was resolved.
D:\Program Files (x86)\MSBuild\14.0\bin\Microsoft.Common.CurrentVersion.targets(1819,5): warning MSB3277: Found conflicts between different versions of the same dependent assembly that could not be resolved. These reference conflicts are listed in the build log when log verbosity is set to detailed.
Now, I know what to do if this error message had come from Visual Studio: Found conflicts between different versions of the same dependent assembly that could not be resolved
The problem is that this error message comes from drilling into "Logs" in the Deployment Centre of my Azure web app (from clicking "Show Logs..." next to "Running deployment command..." I can't figure out where these reference conflicts are listed for an Azure app service despite trying to turn on as much logging as possible and searching for a solution to this problem.
Could someone please show me where to go to see where these conflicts are listed in an Azure app service? Where is the build log? How do I turn it "on"?
EDIT: I just found this: What is the default location for MSBuild logs?. I don't know if it applies to Azure.
Update:
The code is being continuously pulled into my Azure app from my Azure DevOps repository whenever I push a new code change. It's building (which includes compiling) on the server, somewhere. I just don't think there's any way to actually see the build logs. In Visual Studio, all we have is the output window, and there's no equivalent on the server.
Update:
Before viewing logs on Azure, be aware that azure-web-sites do not provide compilation capabilities, so compilation-related warnings and errors are not displayed in the logs. Azure's log feature is used to track runtime warnings or run-time errors, not compile-time.
Since you have deployed to Azure, please have a look of this:
Log stream:
From your description, you need to change the assembly which is mismatch with others.
If you still can't resolve this problem, please add the error and the assembly you used in your app service to this question text.
I had a site running asp.net 5 beta4, and decided to upgrade to beta5. The site runs locally fine. I pushed the changes to master and it was picked up from bitbucket and deployed successfully.
When I try to hit the site in azure, I get a 500 Internal Server Error. I've tried a number of things, but can't seem to track down the root cause of the failure. I'm looking for suggestions as I'm hitting a wall. From what I've tried below it seems like some fundamental initialization is failing.
Here's what I've tried:
Enabling customerrors="off". I added a web.config to the wwwroot folder with system.web/customErrors mode="Off". I've verified that the web.config is populated correctly in the deployed wwwroot and had the appsettings containing the dnxversion etc merged correctly.
Customizing the custom error page, adding runtimeinfo. I have the following set in my Startup.cs:
app.UseErrorHandler("/Home/Error");. I also have set the error page to display the exception. This doesn't seem to be hit.
Attached to the remote process to debug. Visual studio eventually freezes, so haven't gotten anywhere with this.
Enabled application insights. This registers events when I debug locally, but doesn't capture anything from the azure instance.
Enabled application logs and request failure tracing. The detailed errors show a 500.0, without much detailed information.
Imgur
Imgur
I've also verified through the console that the runtime is set correctly to beta5.
Update:
I set the ASPNET_ENV to Development and it loaded with appsettings loaded via the azure portal. Setting ASPNET_ENV to something else isn't working. I also removed any custom code from startup.cs pertaining to the non-development environments, with no help. I'm still looking for a means of capturing the original error.
Assuming you are targeting DNX451 and not dnxcore50, there is a good chance Azure it still trying to run it against the beta4 runtime instead of beta5. If that's the case, you won't get a decent error message.
Try adding an environment variable in Azure "SCM_DNX_VERSION" and set it to 1.0.0-beta5. It looks like kudu was recently upgraded to support beta5 https://github.com/projectkudu/kudu/commit/55175a017779bf493ff8e6ce87b96dd1451f7d7b, so you might want to try to redeploy from bitbucket in the case that the Kudu team has already deployed this change.
For a little more detail, you can check out my previous answer (although it is very dated and references the old "K" names) here:
Deploying ASP.NET vNext beta 2 on Azure with Kudu
Every time you update to a new beta, you will have to update your SCM_DNX_VERSION environment variable.
I have tried multiple ways to get the production SharePoint content to my newly installed local development environment that is running on a VM Windows Server 2008 R2. After an export of the farm and a restore failed I came across this blog post and followed these instrucitons: http://richardstk.wordpress.com/2012/02/03/build-a-sharepoint-2010-development-test-environment/. To sum up, it's basically backing up the live SQL Content database as well as the Profile, Sync and Social databases, then restoring them on the dev machine and pointing SharePoint to use these new databases instead of the old ones. Then after that I deployed the custom webparts to the development server from within Visual Studio.
I've done this and it seemed to work pretty well. I can access Central Administrator as well as setting up a SharePoint Connection within Visual Studio and being able to see all the pages, lists, documents, etc. So it is definitely pointing to the new content database. I should mention I can also connect via SharePoint Designer and access all the correct content, Master Pages, lists, etc.
The problem I am having is that I am getting a "Could not load file or assembly" error when I go to the site in a browser and it takes me to /Pages/Home.aspx. The file is a custom webpart that I have deployed from within Visual Studio. When I look within the GAC I see the assembly listed but the PublicKeyToken is different from the one that is shown in the error message.
When I dig into it a little more I see that the custom user control is registered in my Master page, and when I look at the ascx file in the _controltemplates directory where it is located there is an Assembly that looks like this:
<%# Assembly Name="BlogRoll, Version=1.0.0.0, Culture=neutral, PublicKeyToken=529e9730fe2a198d" %>
That PublicKeyToken is correct for the live site when I look in the GAC there but when I deployed it to my local GAC it created a new PblicKeyToken. Sorry if I'm rambling but I wasn't sure what was relevant and what wasn't.
I guess my question is how to handle this? It doesn't seem smart to change all the ascx files locally to match the new PublicKeyToken's that I have in the local GAC because then when I deploy these changes to live they won't find the appropriate assembly. What is the best way to handle this?
UPDATE
The code in question has a key.snk file that is being used to strongly sign it. My understanding is that this should make it so that it gets compiled with a specific PublicKeyToken each time and therefore install in the GAC with a specific PublicKeyToken. If that is true, then I believe the only reason it would have a different key token on my dev environment versus the production is that the key.snk file that has been provided is incorrect. Is that true?
You could use WSP Builder or WinGac to forcibly deploy the assembly with the correct PublicKeyToken to your local GAC.
I have a 3rd party web page screen capture DLL from http://websitesscreenshot.com/ that lets me target a URL and save the page to a image file. I've moved this code into my Azure-based project and when I run it on my local sandboxed dev box and save to the Azure blob, everything is fine. But when I push the bits to my live server on Azure, it's failing.
I think this is because either MSHTML.dll and/or SHDOCVW.dll are missing from my Azure configuration.
How can I get these libraries (plus any dependent binaries) up to Azure?
I found the following advice on an MSFT forum but haven't tried it yet. http://social.msdn.microsoft.com/Forums/en-US/windowsazuredevelopment/thread/0344dcff-6fdd-4479-a3b4-3e89750a92f4/
Hello, I haven't tried mshtml in the cloud. But generally speaking, to
use a native dll in a Web Role, you add the dll to the Web Role
project just like adding a picture (choose add existing items). Then
make sure the Build Action is set to Content. This tells Visual Studio
to copy the dll file to the output package.
Also check dependencies carefully. A lot of problems related to native
code are caused by missing dependencies, such as a particular VC++
runtime dll.
Thought I'd ask here first before I burn a day or two on an unproven solution.
EDIT #1:
it turns out that our problem was not related to MSHTML.dll or SHDOCVW.dll missing from the Azure server. They're there.
The issue is that by default new server instance have the IE security hardening feature enabled, and this was preventing our 3rd party dll from executing script. So we needed to turn off the enhanced IE security configuration settings. This is also a non-trivial exercise.
In the meantime, we just created a server-side version of the feature on our site we need to make screen captures from (e.g. we eliminated JSON-based rendering of UI on the client), and we were able to proceed.
I think the solution mentioned in the MSDN forum thread is correct. You should put them as part of your project files, so that the SDK will package and deploy them to the VM on the cloud.
But if they are COM and need to be registed you'd better call the register command via the Startup feature. Please check http://msdn.microsoft.com/en-us/hh351539
HTH