I have custome azure utility dll that has one method to read configuration values from ServiceConfiguration and also has fallback code to read from AppSettings from web.config in case RoleEntironment is not running .
This DLLs works fine with Azure WCF project runnning on local and production cloud environment.
For some reason I am hosting this WCF service on Rackspace server on IIS.
On my local machine IIS, WCF service works fine but on Rackspace it crashes with following error:
The type initializer for 'Microsoft.WindowsAzure.ServiceRuntime.RoleEnvironment' threw an exception.
I have copied WindowsAzure.ServiceRuntime.dll, Diagnostics.dll and StorageClient.dll in bin on rackspace. Still it gives same error.
I have also tried copying <startup useLegacyV2RuntimeActivationPolicy="true"> to Web.config, still it does not work.
Any idea? Am I missing more cloud DLLs or some more configuration is needed?
I went through this pain recently. And it ended up being a mismatched version of the Microsoft.WindowsAzure.Diagnostics dll in the Azure project file causing the problem. If you have local working copy and a successful deploy from a previous version you can copy the deployed files from the Azure VM and compare them to your local set (it was the Worker Role that was failing for me). If not check the versions to make sure the version being referenced is included in the deploy with CopyLocal set to true.
I have fixed this problem by adding useLegacyV2RuntimeActivationPolicy="true" in config file
<configuration>
<startup useLegacyV2RuntimeActivationPolicy="true">
<supportedRuntime version="v4.0"/>
</startup>
Related
I have been searching for this error all over the internet but no matter what I try to fix this problem nothing actually works. And the detailed message that I got after I copied a url from fiddler and put it in the browser and is as follows.
Module IIS Web Core
Notification BeginRequest
Handler Not yet determined
Error Code 0x80070003
Config Error Cannot read configuration file
Config File \?\C:\inetpub\wwwroot\myservices\web.config
Actually what has happened in the past that I had this service called "myservices" working all fine when I used visual studio to create a virtual directory for it in IIS. But then what I did, I tried to do a web deploy of this service in IIS and removed ("myservices" from Default Web Site tree which I had created by creating a virtual directory from within VS 2013). And what I observed is, that after I web deployed "myservices" it didn't work the same way as it was working previously when (I created a virtual directory for "myservices" in IIS through VS2013 but had it removed to see whether the web deployed version of it would behave the same way). Therefore when I analyzed the cause of HTTP error 500.19 through Fiddler (for the web deployed service) it said (Config Error Cannot read configuration file and
Config File \?\C:\inetpub\wwwroot\myservices\web.config) but when I physically try to look into the folder C:\inetpub\wwwroot I could never find myservices folder as such (what to talk of web.config file in it). Then I manually created a folder called "myservices" in C:\intepub\wwwroot directory and put my web.config file there to see if the web deployed service would still work, but it didn't. Then I removed this folder called "myservices" and obviously the web.config file inside of it and also removed the web deployed service from Default Web Site Tree.
And now after all this mess even if I go to visual studio and try to create a virtual directory for my service "myservices" (I can see it in Default Web Site Tree in IIS ) but it would throw the same error as http 500.19 as the web deployed version of this service. In other words whatever I tried it messed up my services even when it's not a web deployed version which previously was not the case. I literally request everybody out there to please guide/suggest me with whatever experience they have as to what went wrong in all this trial and error endeavor of mine.
Thanks
This may be a long shot, but sometimes web.config files get corrupted (our code repository occasionally does this) and you cannot see it with the naked eye. take a simple web.config file that you know is not corrupt and start rebuilding the file from there if it works. We have also used a hex editor (like XVI32) where we can see the corruption, but its much easier to rebuild from a fresh file.
If your problem is not the web.config but the virtual folders, then do the same methodology. Start over with what works and go from there. It could be the web deploy tool that is causing the corruption.
When nothing worked, all I did, was uninstalled IIS rebooted my machine re-installed it again and the HTTP 500.19 is gone.It seems like my IIS was corrupted.
We have our code in a Visual Studio Online TFS repository,
and we build and deploy to Azure. We have a Build Definition using the Hosted Build Controller, and the TfvcContinuousDeploymentTemplate.12.xaml
build process template which is configured to deploy to our Windows Azure Deployment Environment.
Everything was working fine until we upgraded our Azure Cloud Service VM from Small to the Standard_D1 size.
We made the appropriate change to the WebRole in our ServiceDefinition.csdef:
<?xml version="1.0" encoding="utf-8"?>
<ServiceDefinition name="PriceCalv3CS" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition" schemaVersion="2014-06.2.4">
<WebRole name="PriceCalv3CS.SPA" vmsize="Standard_D1">
...
</WebRole>
</ServiceDefinition>
And everything still works fine if we publish and deploy from our local Visual Studio 2013... but not from Visual Studio Online.
VSO compiles the solution successfully, but then throws this exception when trying to deploy:
Exception Message: Invalid enum value 'Standard_D1' cannot be deserialized into type 'Microsoft.TeamFoundation.Deployment.Workflow.AzureManagement.v1_7.InstanceSize'. Ensure that the necessary enum values are present and are marked with EnumMemberAttribute attribute if the type has DataContractAttribute attribute. (type SerializationException)
Exception Stack Trace: at System.Runtime.Serialization.EnumDataContract.ReadEnumValue(String value, Int32 index, Int32 count)
at System.Runtime.Serialization.EnumDataContract.ReadEnumValue(XmlReaderDelegator reader)
at System.Runtime.Serialization.EnumDataContract.ReadXmlValue(XmlReaderDelegator xmlReader, XmlObjectSerializerReadContext context)
...
It seems that VSO cannot handle the new(ish) instance size names that Azure now supports.
We are using Microsoft Azure SDK for .NET (VS 2013) - 2.5.0,
and tried upgrading to the latest 2.5.1, but that didn't help VSO.
The other references I've seen to this problem are in social.msdn
where there was a bug opened that was closed with no resolution.
Someone with a similar error was able to resolve it by deleting their old builds,
but that didn't work for me. I tried creating a brand-new Build Definition, but that didn't help either.
It seems like we need to tell VSO to respect these new instance sizes. But how?
MORE: I thought VSO was parsing the ServiceDefinition.csdef, and choking on vmsize="Standard_D1", but that's not the case. I changed it to vmsize="Small" and even vmsize="broken" and the error message still complains about "Invalid enum value 'Standard_D1'".
If your previous instance was smaller than d1 then your deploy is in a datacenter that does not support D1.
If that is the case then you need to delete your current deployment, both vm and resource group. When you then do a new deploy as D1 your instance will end up in the correct data center.
I have an Asp.Net 5 application published on Azure, that is returning a 500 Internal Error.
After disabling custom errors on web.config file, this is the error being displayed:
It's an odd behaviour, since everything on web.config seems fine. Directories are correct and I've checked them:
And then, there's the web.config file, which seems also correct:
Packages on project.json are in beta2.
Runtime on project is set to KRE x86 beta2
What might be happening? Looks like a problem on Azure, the website runs fine on the development machine.
I'm trying to build a Web Deploy package via msbuild on a new machine and it's not working. It builds fine on other machines, but here I get the following vague error:
...\Microsoft.Web.Publishing.targets(2767,5): error : Filename: redirection.config
...\Microsoft.Web.Publishing.targets(2767,5): error : Error: Cannot read configuration file
...\Microsoft.Web.Publishing.targets(2767,5): error :
...\Microsoft.Web.Publishing.targets(2767,5): error : Unknown error (0x80005000)
I'm not sure what 'redirection.config' is, and the line reference to the .targets file doesn't help at all.
How can I fix this?
redirection.config is a file that lives in the IIS configuration directory, typically %SystemRoot%\System32\inetsrv\config. Here are two possibilities:
The account building your project doesn't have access to the IIS config dir. This might happen if you have an automated build identity with special permissions, or you if you need to start Visual Studio as an administrator.
You don't have IIS installed at all on the new machine. Check to be sure the IIS config directory, and redirection.config in particular, even exist. If not, you'll need to install IIS.
If you receive this error when deploying with Release Managment (via IISConfig.exe) be sure that the deployment agent service account is in the local Administrators group. You may need to restart the deployment agent service.
Similar Issue resolved below - Might help
Insufficient Permissions Problems with MSDeploy and TFS Build 2010
For me, simply running visual studio as admin gave it the elevated permissions it needed to operate against this folder.
May work for others.
I got this error when I tried to use a relative path for the contentPath setting. I fixed it by settings the contentPath to the full path of the folder. Without the full path, the contentPath provider thinks it is a site path or application path and looks for it in in the IIS configuration.
This error just appeared to me when my C# project was referencing the Microsoft.Web.Administration, Version=7.9.0.0 assembly. It looks like this assembly only works with IIS Express. For IIS, we must use Microsoft.Web.Administration, Version=7.0.0.0.
After hours of testing and troubleshooting this problem turned out to be an issue with the users profile.
This was found by logging in as myself and I didn't receive the same issue.
To fix this issue:
Log into the machine as an administrator and delete the contents of the corrupt profile from C:\Users (or rename the folder to username.OLD)
Open up the registry and navigate here – HKLM\SOFTWARE\Microsoft\Windows NT\ CurrentVersion\ProfileList
Find the corrupt profile and rename this to .OLD or remove it.
You can read more about it at this article.
As this is high in search engines when looking for this error, I'll post my solution.
I used Azure Pipelines to release the app to IIS and had this error. My issue was that I mistakenly used Build Agent job instead of Deployment Group job when configuring the release pipeline.
On server 2012 this error can be caused by UAC which needs to be disabled via the registry.
This article explains why...
https://social.technet.microsoft.com/wiki/contents/articles/13953.windows-server-2012-deactivating-uac.aspx
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\policies\system
change DWORD "EnableLUA" from 1 to 0
I have ASP webrole that works great without ACS. When i add ACS to the my application it works fine locally. However when i deploy it to the cloud its doesnt seem to be packaging the Microsoft.IdentityModel.dll.
Now I have done the following:
Ensured under the References that copy local = true for "Microsoft.IdentityModel"
Tired re-adding the STS references.
3.Right click>>Add referance>>Microsoft.IdentityModel.dll
This used to also work fine without having to install WIF on the actual server.
Any ideas?
Please check out these resources, which might help you solving your issue:
Similar SO Question
MSDN Documentation: Unable to Find Assembly 'Microsoft.IdentityModel' When RoleEnvironmentAPIs are Called
ACS Walkthrough from Windows Azure Team (new)
Powershell script on GitHub for Installing WIF via Stratup Task
Hope this helps!
I manage to find what was causing the issue. So I had 1 x WebRole and also 1 X WCF role in the same solution. ACS worked fine up until three steps later in the application once I tried to use the WCF service. At point it stuck me that the Azure creates a VM per role. So this made total since why it authenticated fine up to the point when I tried to use the WCF service. The assembly was not missing from the WebRole but rather from the WCF VM that it created. So I made sure that WIF was also installed on that VM and bang it worked. I still don’t understand 100% why I would have to have to install WIF on the WCF VM but in the end that what was causing my issue.
The only thing that worked for me is described in this post under "using windows update packages section" (but I had to make some minor changes to the startup script)
Basically, I had to create a Startup Task, which executes batch file InstallWif.cmd that I've created under my web project. I also downloaded and included WIF install package (Windows6.0-KB974405-x64.msu) into my web project. I set "Copy to Output Directory" property to "Copy Always" for both of these files.
InstallWif.cmd contained the following script
#echo off
sc config wuauserv start= demand
wusa.exe "%~dp0Windows6.0-KB974405-x64.msu" /quiet /norestart
sc config wuauserv start= disabled
exit /b 0
Note that I had to use Windows6.0-KB974405-x64.msu and not Windows6.1-KB974405-x64.msu. I found out that 6.1 version wouldn't install by logging to Azure VM instance using a remote desktop connection to Azure and trying to manually install this version there.
Startup task is defined inside ServiceDefinition.csdef file like this
<Startup>
<Task commandLine="InstallWif.cmd" executionContext="elevated" taskType="simple" />
</Startup>