We Keep Coding

diagnostics not working in web role for Azure SDK 2.5.1

I am working with Azure SDK 2.5.1, mainly on the new designed diagnostics stuffs. However, I found I cannot get it run for my web role.
So, I created a cloud service project, added a web role. Then, I appended one Trace message at the end of Application_Start in Global.asax.cs:
Trace.TraceInformaction("Application_Start end.");
After that, I right clicked the WebRole and opened the Properties tab. In the diagnostics config window:
General: I choose 'Custom plan', also specified the storage account, keep the 'Disk Quota in MB' as default '4096'
Application Logs: 'Log level' switch to 'All', others kept as default
Other tabs are in default config settings
After I deployed the project to cloud, I found some unexpected things:
There is no WADLogsTable exists in Table storage. That's very strange, if I use a Worker Role, it would work as expected. So in web role, I just cannot find the Trace logging?
For the performance counters, since I am using the default config with 8 counters, I can only see 8 in WADPerformanceCountersTable table storage. In my assumption, over time, there would be more and more values of this 8 counters transferred to this table. But it was just not happened, after several hours, it still had that 8 counter values.
I just thought the diagnostics for Web Role just crashed or not working at all. Meanwhile, I checked the logs located at "C:\Logs\Plugins\Microsoft.Azure.Diagnostics.PaaSDiagnostics\1.4.0.0\DiagnosticsPlugin.log" in server, at the end of this file there is an exception said some diagnostics process exit:
DiagnosticsPlugin.exe Error: 0 : [4/25/2015 5:38:21 AM] System.ArgumentException: An item with the same key has already been added.
at System.Collections.Generic.Dictionary`2.Insert(TKey key, TValue value, Boolean add)
at Microsoft.Azure.Plugins.Diagnostics.dll.PluginConfigurationSettingsProvider.LoadWadXMLConfig(String fullConfig)
DiagnosticsPlugin.exe Error: 0 : [4/25/2015 5:38:21 AM] Failed to load configuration file
DiagnosticsPlugin.exe Information: 0 : [4/25/2015 5:38:21 AM] DiagnosticPlugin.exe exit with code -105
From MSDN, the code -105 means:
The Diagnostics plugin cannot open the Diagnostics configuration file.
This is an internal error that should only happen if the Diagnostics
plugin is manually invoked, incorrectly, on the VM.
It doesn't make sense, I did nothing to the VM.
As I said above, I just did very tiny changes to the scaffold code generated by Visual Studio 2013. Did I do something wrong or it's a bug for Azure SDK 2.5?
By the way, it seems everything is ok for Worker Role.

Quote from MSDN forum:
Hey folks jumping it late here but just wanted to confirm that there was an issue with the initial 1.4.0.0 diagnostics extension where the plugin could crash on the web role under certain circumstances.
The issue has since been resolved with 1.4.1.0. If you re-apply the extension on the role you should automatically get the latest version which fixes the issue.
At early stage, the diagnostics in SDK 2.5.1 has some internal issue inside, but Microsoft already fixed it.
Anyway, we have newer version can be applied, so this is not a problem anymore, just in case you meet this issue too.

Expression Encoder 4 in a WCF service

I am trying to write a WCF service that would run in IIS 8 and would use the Expression Encoder SDK to open a video file and then encode it as a WMV. The following code works fine when it's in a desktop application I wrote earlier.
Job job = new Job();
job.ApplyPreset(Preset.FromFile(HttpRuntime.AppDomainAppPath + "Profiles\\" + profile + ".xml"));
job.CreateSubfolder = false;
job.SaveJobFileToOutputDirectory = false;
job.OutputDirectory = Path.GetDirectoryName(input);
MediaItem item;
item = new MediaItem(input);
item.OutputFileName = "{Original file name}.wmv";
job.MediaItems.Add(item);
job.EncodeProgress += new EventHandler<EncodeProgressEventArgs>(job_EncodeProgress);
job.EncodeCompleted += new EventHandler<EncodeCompletedEventArgs>(job_EncodeCompleted);
job.Encode();
But when I try to run this code in a WCF service running on IIS I get the following error
The type initializer for 'Microsoft.Expression.Encoder.SkuManager' threw an exception.
at Microsoft.Expression.Encoder.SkuManager.IsFeaturedSupported(Feature feature)
at MS.Internal.Expression.Encoder.FastProperties.FastPropertyCreate.ShouldAddProp(IFastProperty property, PropertyType propType)
at MS.Internal.Expression.Encoder.FastProperties.FastPropertyCreate.CreatePropertiesArray[T](Type classType, PropertyType propType)
at MS.Internal.Expression.Encoder.FastProperties.FastPropertyCreate.GetProperties[T](PropertyType propType)
at MS.Internal.Expression.Encoder.Persistence.JobPersistence.GetJobFilePropertiesCore[T](JobPropertiesMode mode)
at MS.Internal.Expression.Encoder.Persistence.JobPersistence.GetJobFileProperties[T](JobPropertiesMode mode)
at Microsoft.Expression.Encoder.JobBase.CreateDefaultValues(JobBase job)
at Microsoft.Expression.Encoder.JobBase..ctor()
at Microsoft.Expression.Encoder.Job..ctor()
I can run this code in a regular desktop application on the server, but not in a WCF service running on the same machine.

It turns out it was a permissions problem in IIS.
In order for any program to use the Expression Encoder SDK it needs to be running under an identity that can access the Expression Encoder program installed on the machine.
So in IIS the "ApplicationPoolIdentity" identity that the WCF service was running on didn't have permissions to launch the Expression Encoder program that was installed on the machine by the "Administrator" account.
To fix this you can do one of two things.
When you are installing Expression Encoder allow "All Users" to be able to launch it.
When you install your WCF service on IIS make sure it's running in an application pool that can launch Expression Encoder

I had this same issue in an iis8 web site (not hosting any wcf service tho) and yes i also discovered that IIS needs to run under permissions that can execute expression encoder. BUT one day it just stopped working and started throwing the same error:
"The type initializer for 'Microsoft.Expression.Encoder.SkuManager' threw an exception."
Even though the AppPool's identity was a good one. I pulled my hair out for a day or so then realized that somehow the binaries that VS copies to the local bin directory didn't want to be run in IIS. Somehow corrupted or dll mismatch with expression's installation???. I had to delete the contents of the bin directory and, then VS replaced them, and it worked. Setting CopyLocal to false for those references did not work (conceivably it might be nice to just use from the gac).

TFS WorkItemStore throws COMException in ASP.NET MVC app when using Authentication

I'm completely stumped by this and endless google/stackoverflow searches haven't helped. I'm using the 2012 Visual Studio SDK to connect to TFS 2012 and query the work item store. The code below works perfectly fine in both a console application and an ASP.NET MVC app that does not use authentication, or in any scenario that's run on my local machine. However, I get a COMException when I try to instantiate a WorkItemStore from within an MVC app that's been deployed to the server and uses (Windows) authentication.
It makes no difference if I have the <authentication mode="Windows" /> element in my web.config or not; as long as there is an [Authorize] attribute on my controller or any of its action methods, I get an exception as soon as the last line of code below is invoked. If I remove the [Authorize] attribute, the exception does not occur. If I call the code below at some point before calling code decorated with [Authorize], the exception does not occur. Somehow, using the AuthorizeAttibute is inducing this exception.
Any ideas of how to resolve this? Or at least for more exactly identifying the real root problem? I'd really like to understand what is going on here.
Uri tfsAddress = new Uri("http://tfs-address:8080/tfs/DefaultCollection");
var myCreds = new NetworkCredential("userName", "password", "domain");
var tfsCreds = new TfsClientCredentials(new WindowsCredential(myCreds), false);
var defaultCollection = new TfsTeamProjectCollection(tfsAddress, tfsCreds);
defaultCollection.EnsureAuthenticated();
var store = defaultCollection.GetService<WorkItemStore>(); // <-- EXCEPTION
Stack trace:
[COMException (0x80004005): Error HRESULT E_FAIL has been returned from a call to a COM component.]
Microsoft.TeamFoundation.WorkItemTracking.Client.DataStore.DataStoreNative.BeginDataStoreInit(IntPtr handle, String defaultCachePath, String instanceId, Int32 cacheVersion) +0
Microsoft.TeamFoundation.WorkItemTracking.Client.DataStore.Datastore.BeginDataStoreInit(String defaultCachePath, String instanceId, Int32 cacheVersion) +56
Microsoft.TeamFoundation.WorkItemTracking.Client.WorkItemStore.InitializeInternal() +598
Microsoft.TeamFoundation.WorkItemTracking.Client.WorkItemStore.Microsoft.TeamFoundation.Client.ITfsTeamProjectCollectionObject.Initialize(TfsTeamProjectCollection teamProjectCollection) +23
Microsoft.TeamFoundation.Client.TfsTeamProjectCollection.InitializeTeamFoundationObject(String fullName, Object instance) +43
Microsoft.TeamFoundation.Client.TfsConnection.CreateServiceInstance(Assembly assembly, String fullName) +91
Microsoft.TeamFoundation.Client.TfsConnection.GetServiceInstance(Type serviceType, Object serviceInstance) +200
Microsoft.TeamFoundation.Client.TfsTeamProjectCollection.GetServiceInstance(Type serviceType, Object serviceInstance) +439
Microsoft.TeamFoundation.Client.TfsConnection.GetService(Type serviceType) +241
Microsoft.TeamFoundation.Client.TfsConnection.GetService() +58

The solution was to change the identity of the application's AppPool to either a domain account or to LocalSystem.
I can't say I fully understand what is going on behind the scenes here, but it seems there was some kind of conflict between the authenticated identity of the user browsing the site and the AppPool identity, which was originally the default ApplicationPoolIdentity. If the root cause of the problem is unauthorized access or something similar, it seems to me that I should have gotten the same exception for anonymous users as well as authenticated ones. I'd also expect an actual Unauthorized Access Exception, not an 'undefined' COMException, so I really don't know what the real root cause is. If someone comes across this question and cares to elaborate, please do so.

For me this error appears under certain situations, like when I created a new site in local IIS which uses the TFS API. I even followed the comments here to no avail, I had the AppPool Identity set to LocalSystem. I had a separate app pool. I had 32bit applications enabled for the TFS API.
For me the problem ceased when I changed the app pool from framework v4.0 to v2.0 and then back to v4.0.
I don't know why it fixed the issue, but it worked for me.

The accepted answer worked for me, but didn't seem optimal. I was able to fix this by also deleting the below cache directories and/or giving the application pool user permissions to them.
Windows 7:
C:\ProgramData\Microsoft Team Foundation
Windows 8.1:
C:\ProgramData\Microsoft\Team Foundation
These folders seem to be created whenever my applications utilize the TFS SDK.

Check this response
http://social.msdn.microsoft.com/Forums/vstudio/en-US/e4c84467-309a-45bd-9da8-973732897440/problem-with-microsoftteamfoundationworkitemtrackingclientdatastore?forum=tfsgeneral (Read All)
http://blogs.msdn.com/b/buckh/archive/2012/02/01/listing-the-work-items-associated-with-changesets-for-a-path.aspx

Why am I getting SEHException when calling RoleEnvironment.GetConfigurationSettingValue("MYKEY")?

I'm trying to call RoleEnvironment.GetConfigurationSetting("SOMEKEY") like so:
public partial class AzureBasePage : System.Web.UI.Page
{
protected ChargifyConnect Chargify
{
get {
if (this._chargify == null) {
this._chargify = new ChargifyConnect();
this._chargify.apiKey = RoleEnvironment.GetConfigurationSettingValue("CHARGIFY_API_KEY");
}
return this._chargify;
}
}
private ChargifyConnect _chargify = null;
}
My ServiceConfiguration.cscfg key looks like this:
<Setting name="CHARGIFY_API_KEY" value="AbCdEfGhIjKlMnOp" />
And I get this error:
Exception Details: System.Runtime.InteropServices.SEHException: External component has thrown an exception.
[SEHException (0x80004005): External component has thrown an exception.]
RoleEnvironmentGetConfigurationSettingValueW(UInt16* , UInt16* , UInt32 , UInt32* ) +0
Microsoft.WindowsAzure.ServiceRuntime.Internal.InteropRoleManager.GetConfigurationSetting(String name, String& ret) +92
Microsoft.WindowsAzure.ServiceRuntime.RoleEnvironment.GetConfigurationSettingValue(String configurationSettingName) +67
ChargifyNET.ChargifyAzurePage.get_Chargify() in C:\NetProjects\ChargifyDotNET\Source\Chargify.NET\ChargifyAzurePage.cs:26
Chargify.Azure._Default.Page_Load(Object sender, EventArgs e) in C:\NetProjects\ChargifyDotNET\Source\Chargify.Azure\Default.aspx.vb:8
System.Web.UI.Control.OnLoad(EventArgs e) +99
System.Web.UI.Control.LoadRecursive() +50
System.Web.UI.Page.ProcessRequestMain(Boolean includeStagesBeforeAsyncPoint, Boolean includeStagesAfterAsyncPoint) +627

You will get the SEHException if you attempt to access RoleEnvironment if you're not running in the dev fabric or Azure fabric. I believe you're inadvertently running your website under the asp.net development server, meaning you're not in the dev fabric (I've confirmed that this will throw an SEHException). In other words, you've either set your website project as the startup project, or you've right-clicked it and told it to run.
You must set the cloud project itself as the startup project, which will then show your website running on port 81 by default. The cloud project is the project that has, as its members, all of your role definitions. You can look at your browser's URL bar and easily tell if you're running in the asp.net dev server, because you'll be on some random port number instead of port 81.
You should make sure you're running in the dev fabric or Azure fabric by checking RoleEnvironment.IsAvailable. If that's true, you're safe to call anything in RoleEnvironment. If it's false, you're not running within the fabric.

Removing the <Sites> tag in the ServiceDefinition.csdef file could be a workaround for you as was for us but then your site will not be deployed to Full IIS on the Cloud. We are using 1.7 of the SDK.
So in summary: RoleEnvironment.IsAvailable = False with this included in the ServiceDefinition.csdef with an instance count of 1 I might add.
<Sites>
<Site name="Blah">
<Bindings>
<Binding name="Endpoint1" endpointName="Http" />
<Binding name="Endpoint1" endpointName="Https" />
</Bindings>
</Site>
</Sites>
Remove the <Sites> node and deploy and you might find that now RoleEnvironment.IsAvailable = True.
There are very little logs about what is actually happening - the website is running fine, there are no warnings except the usual you only have 1 instance why not deploy 2 and the site is up and running fine.
This is a recent issue and I believe there must be some changes made in that msshrtmi.dll. It could log a little more of what might actually be the problem if the RoleEnvironment is not available.

To follow up on that, just in case someone runs into the same problem again, it might also be the case that for whatever reason one of your deployments got stuck in the compute emulator.
What happened to me was that I had a webrole containing multiple websites, each bound to a different hostname. Say: localhost and test.localhost. Normally, you would access these at localhost:81 and test.localhost:81. For some strange reason though, one deployment got into a weird state where it would be listed in the compute emulator, with no Visual Studio debugging it, it would say "Role Instance destroyed" or something along those lines.. This deployment still had the websites deployed in IIS. I then, without knowing about this buggy deployment, accessed the default urls, ie. test.localhost:81 which would load up the old deployment files. The (old) site worked until I opened a page that actually used the RoleEnvironment.GetConfigurationSettingValue method, and only then I got that exception. It was really frustrating as this boggus deployment obvioulsy didn't hit any breakpoints nor breaked on exceptions, yet it looked exactly as the site I've been working on..
When I realised this, I opened the hostnames under the new port and there the pages worked as expected. Once I removed this buggy deployment from the compute emulator the IIS websites also got deleted and thankfully the ports are now available for use as expected..

If you get the same error after making sure you are running the dev fabric, try reducing the instance count to one. That fixed it for me.
Still, seems weird that I can't debug with 2 instances.

Although many point out that you should run with dev/Azure fabric instead of the asp.net development server, I think it's worth mentioning that you need to choose the correct execution model when you publish your application to Azure if you want to use the RoleEnvironment.
There're 3 models as of now:
VM
Web Site
Cloud Service
Please refer to here: http://azure.microsoft.com/en-us/documentation/articles/fundamentals-application-models for more details.
And especially the following paragraph:
Cloud Services, which was the initial execution model provided by
Azure, is an explicitly PaaS approach. While the line between PaaS and
web hosting is blurry, Cloud Services differs in some important ways
from Web Sites, including the following:
Unlike Web Sites, Cloud Services gives you administrative access to your application's VMs. This lets you install arbitrary software that your application needs, something that's not possible with Web Sites.
Because Cloud Services offers both web roles and worker roles, it's a better choice than Web Sites for multi-tier applications that need separate VMs for their business logic.
Cloud Services provides separate staging and production environments, making application updates somewhat smoother than Web Sites.
Unlike Web Sites, you can use networking technologies such as Azure Virtual Network and Azure Connect to hook on-premises computers to Cloud Services applications.
Cloud Services lets you use Remote Desktop to connect directly to an application's VMs, something that's not possible with Web Sites.
You can check the RoleEnvironment.IsAvailable. If it is false, your application is not running with Azure runtime, which means the RoleEnvironment is not applicable.

ASP.NET Access to the temp directory is denied

I'm experiencing this problem today on many different servers.
System.UnauthorizedAccessException: Access to the temp directory is denied.
The servers were not touched recently. The only thing that comes in my mind is a windows update breaking something.. Any idea?
This happens when trying to access a webservice from an asp.net page
System.UnauthorizedAccessException: Access to the temp directory is denied. Identity 'NT AUTHORITY\NETWORK SERVICE' under which XmlSerializer is running does not have sufficient permission to access the temp directory. CodeDom will use the user account the process is using to do the compilation, so if the user doesnt have access to system temp directory, you will not be able to compile. Use Path.GetTempPath() API to find out the temp directory location.
at System.Xml.Serialization.Compiler.Compile(Assembly parent, String ns, XmlSerializerCompilerParameters xmlParameters, Evidence evidence)
at System.Xml.Serialization.TempAssembly.GenerateAssembly(XmlMapping[] xmlMappings, Type[] types, String defaultNamespace, Evidence evidence, XmlSerializerCompilerParameters parameters, Assembly assembly, Hashtable assemblies)
at System.Xml.Serialization.TempAssembly..ctor(XmlMapping[] xmlMappings, Type[] types, String defaultNamespace, String location, Evidence evidence)
at System.Xml.Serialization.XmlSerializer.FromMappings(XmlMapping[] mappings, Evidence evidence)
at System.Web.Services.Protocols.XmlReturn.GetInitializers(LogicalMethodInfo[] methodInfos)
at System.Web.Services.Protocols.HttpServerType..ctor(Type type)
at System.Web.Services.Protocols.HttpServerProtocol.Initialize()
at System.Web.Services.Protocols.ServerProtocol.SetContext(Type type, HttpContext context, HttpRequest request, HttpResponse response)
at System.Web.Services.Protocols.ServerProtocolFactory.Create(Type type, HttpContext context, HttpRequest request, HttpResponse response, Boolean& abortProcessing)

Have you checked the permissions on the temp folder? In these cases, the easiest and quickest solution is usually to re-run the aspnet_regiis -i command to re-install the asp.net framework which also resets the permissions on the required folders. Failing that, try using Process Monitor to check what's going on and modify the permissions accordingly.

I had the same issue and none of the above solved our issue -- we restored service temporally by changing the setting that each app pool site was running under - you can do this by going into app pools--> idenity tab and and changing user from Network Service to local user- while we figured out what the problem was(this is not recommended- so if you choose to do this make sure you understand the repercussions)
We then found a link about the Temp\TMP mappings and how to fix them -Which was not our issue
On another site (and as described in other answers) we used Path.GetTempPath() to see what the CLR was actually looking for it turned out to be
C:\WINDOWS\system32\config\systemprofile\Local
Settings\Temp folder
We then used Process Monitor to verify this was in fact correct, when we changed the permission on this folder it worked correctly. We are still unsure as to why the CLR choose to stop using the default temp directory but we did find a link as to how it makes that decision. How GetTempPath is picked.
Update: We Finally figured out HOW our Temp folder PATH was changed when Someone decided to repeat the error! The Issue was the CLR Profiler someone decided to run on live which changes all permissions of the temp directory so If you didn't already know this already I would not recommend running it on a Prod server.

Whatever the reason for the sudden change, you can probably solve the problem using the steps described in the exception.
Call Path.GetTempPath to find out what it thinks the temporary directory is, it may not be what you think it is.
Go to that directory and give the user 'NETWORK SERVICE' the permissions it needs, probably Read/Write.

Indeed its a web site running in IIS? and accessing a web service.
It's either running as ASPNET, anonymous, or impersonating the user connected or finally the web service itself is connecting as a 'user'.
Whichever user it is may not have access to the temp directory. Odd how nothing has changed :). However Windows Service packs can change security settings.

Windows Server 2003 - IIS 6.0 - Same issue. c:\windows\temp = current temp directory - using procmon as suggested by cgreeno allowed me to see access denied. I granted the user 'Everyone' full rights to the c:\windows\temp folder, but still getting access denied. Granted full rights access to all users in the mix (Local System, Network Service, app pool identity user, etc.) but no help. Tried ASPNET_REGIIS -ir but no help.
I created a new local system user 'tempuser' and assigned to local 'Administrators' group. I navigated to Windows Services and stopped 'World Wide Web Publishing', 'IIS Admin', and 'HTTP SSL'. I assigned 'tempuser' to all three services. I tried to start each of the services, but they failed to start for a variety of reasons. I then put all 3 services back to user 'Local System' and suddenly my access denied error went away. Don't know why. Was having other file system errors with my App Pool user, but those now are working correctly too. It appears something with the assignment of the Local System account with windows services was awry.
* UPDATE *
Problem came back. Very weird...

In my case antivirus(COMDO) was responsible for this... After antivirus updated it just started to block access to temp folder for my local services(not all, just few) ... it was kinda tricky to figure it out..

Goto into roslyn folder (into bin foloder of your project) and add the read/write permissions at the user which runs the application pool