I took over this 4.0 webforms website and got the exact same code from the former developer.
It runs fine on his local machine, but it craps out on my local machine having anything to do with the “System.Web.Security” namespace.
If I put a breakpoint where it is failing and try to fall into the code for that namespace, it won't let me go any further. It just simply will not execute anything to do with the namespace. This happens with all of the three major browsers
Since this forum does not allow any attachments, I can't show you anything more.
Does anybody have any ideas what is wrong?
Turned out to be a simple permissions issue on our end not allowing my id to have access to the database.
I've rebooted my computer 50-100 times this week. I find I can start / deploy locally usually 3-4 times before getting this message:
"Windows Azure Tools for Microsoft Visual Studio
Role instances are taking longer than expected to start. Do you want to continue waiting?"
The solution to get me going again is rebooting.
I know it's not a new problem. I recall that MS agreed it was a problem but does anyone have a solution that does not involve going back to the Hosted Web Core. Seems like this problem is something a lot of people get and it's been around without a resolution (that I know of) for 4-5 months or more.
Now I'll get back to doing another reboot !!!!!
I had this same problem, but could eventually get it to start after dismissing 2 or 3 of the
"Role instances are taking longer than expected to start"
message boxes.
I then found that the problem seemed to be that the Diagnostics were enabled and the storage account was set to something invalid in the Role configuration (.cscfg).
Solved it by going into the UI and disabling diagnostics, I found it would run ok.
To get the UI, right click on the created Role inside the Roles folder in the Solution Explorer.
Then I re-enabled Diagnostics and it auto-populated "UseDevelopmentStorage=true", and this seems to work fine.
From what I understand, there are a few different things that can cause this issue.
For me, I encountered this error after I created a Windows Identity Foundation Startup Task for my Azure deployment and then tried to run my application using the Azure Emulator.
Basically, all I needed to do was change the taskType of the Startup Task from simple to background
ServiceDefinition.csdef
<Startup>
<Task commandLine="Startup\IdentityGac.cmd" executionContext="elevated" taskType="background"></Task>
</Startup>
Based on your question, I'm not sure if this applies to your project, but I figured it would at least be worth mentioning.
You can read my full blog post here.
A new cause for this problem was introduced in Feb 2016.
Using Windows 8.1, Visual Studio 2012 Update 5 and Azure Emulator 2.3
Installing this windows update: KB3126593 will leave you in a situation where the emulator will never start and you'll see this in the Emulator UI.
Uninstalling the update fixes the emulator.
Control Panel > All Control Panel Items > Programs and Features > Installed Updates
Security Update for Microsoft Windows (KB3126593), right-click, uninstall.
(Upgrading to Windows 10 also solves the problem.)
I was also facing the same issue. From looking into the Emulator UI I found that it was trying to read some date from storage area and was failing.
So what I did, I went to location %appdata%\local and deleted all data from folders
1. DevelopmentStorage
2. dftmp
After that restarting the service, every thing started working
For me, the problem was related to caching. The problem started with a warning that said something like, "unable to install cache....exe," but I only saw the error once. After that, the emulator stalled every time. After reading this blog I tried disabling and then re-enabling caching, which fixed the problem.
After I some further investigation I found that the critical issue was this entry in ServiceConfiguration.Local.cscfg:
<Setting name="Microsoft.WindowsAzure.Plugins.Caching.ConfigStoreConnectionString" value="UseDevelopmentStorage=true" />
Previously this connection string had been pointing to a cloud storage connection.
In my experience this can happen if one of your roles does not stop when OnStop() is called. Look for WaWorkerHost.exe (I think). You might also try killing IisConfigurator.exe (or something like that). You know you've got the right process when your task manager list gets dramatically shorter :-)
I encountered the same issue and found the following steps resolved it (I stumbled across this solution when applying the answer from #RobPotter above).
First, opene the ServiceDefinition.csdef file and added this entry:
<Import moduleName="Diagnostics" />
To the: ServiceDefinition / WebRole / Imports node.
Second, add the following diagnostics configuration setting to the necessary .cscfg files:
<Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString" value="UseDevelopmentStorage=true" />
under: ServiceConfiguration / Role / ConfigurationSettings for the web role.
FYI. My Service Definition value for schemaVersion is "2012-10.1.8". The issue may have arisen when I migrated my solution from SDK 1.7 to 1.8
I can't solve the problem after followed all the solutions above.
Finally, I decided not to let it stop my coding any more, just changed the StartUp Project from the 'Cloud Project' to the 'WebRole Project', and F5, ... OK website runs properly on my IIS Express.
So, I think, if it can publish to Azure, and can debug website local, so just let it work in this way, until Microsoft make it easier to use.
(my AzureSDK is 2.0)
Similar to answers above. I was running a startup script and it was running appcmd.exe, however, due to a mistake, the section I was trying to unlock caused an error, which made the roles fail to start.
I had used:
%windir%\System32\inetsrv\appcmd.exe unlock config /section:system.webServer/security
but this is an error and should have been
%windir%\System32\inetsrv\appcmd.exe unlock config /section:system.webServer/security/access
For me, this only happened when I had the checkbox for "Enable Caching" selected. And for me, the problem was that I was running my project off of a UNC Share (actually its running in a VM on my macbook). When I'd start the debugger after checking the "Enable Caching" box on the worker role, it would just hang. Come to find out, about every 2 seconds it was creating a 160MB dump file in C:\Windows\System32\%LOCALAPPDATA%\CrashDumps. After debugging one of those, I could see the first error was when it tried to start cmd.exe on the caching stuff in my worker role and it said CMD cannot be run on a network share, so it would default to windows/system32 or something.
That's when I found this handy dandy 7 year old MS KB article: http://support.microsoft.com/kb/156276 When I added DisableUNCCheck REG_DWORD and set the value to 0 x 1 (Hex) under the registry path HKEY_CURRENT_USER\Software\Microsoft\Command Processor everything started up just like a champ. Hopefully this helps someone else.
I have faced the same issue and spent lots of hours including checking all of the rest answers of this post. I just delete my application under the roles and again add webrole project in current solution. And working fine for me.
I had similar issue. I was executing an .cmd file to register a dependent DLL during the start of the debug session. The .CSDEF file looks like:
<ServiceDefinition name="WorkerRole.Azure" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition" schemaVersion="2014-06.2.4">
<WorkerRole name="SampleWorkerRole" vmsize="Small">
<Startup>
<Task commandLine="register.cmd" executionContext="elevated" taskType="simple" />
</Startup>
</WorkerRole>
</ServiceDefinition>
After starting the Visual Studio using "Run as Administrator" option, this issue did not occur. i was able to debug the application as usual.
My environment is:
Windows Service 2012 R2 + VS 2013 Update 3 + Azure Tools 2.2
Uninstall Windows update KB3126593 works for me!!!
When I Press F5 to run the Azure project containing two worker roles and a web role. It opens two windows with same URL and they take so much time to open as well.
By time consuming, I mean, the website is taking too much time to load, but no such functionality or code is to be executed in the controller.
Can any body guide me on this?
It takes more time to start Azure project simply because it does more stuff. Just for starters, every time you press F5, it creates and configures new application pool for each role, then it creates and configures new web sites for each role instance.
I found it sometimes much faster to start the sites by pressing Ctrl+F5 (i.e. start without debugging). Then you can attach to your process manually, but you are free to do modifications to many files without re-deploying roles. This is especially helpful if you modify something that does not require rebuilding your binaries.
For your other question, you can control how browsers are launched for HTTP and HTTPS endpoints by using Configuration tab of the role properties. Just uncheck endpoints you don't want your browser to be launched on.
Try using the last Azure SDK edition v1.4. With the previous versions of the SDK there were some performance problems when running a service locally. Regarding the two opened windows problem, this might happen because the compute and the storage emulator were started manually on the local machine and not by the Visual Studio. At least in my case this was the problem. After shutting down the app., the compute and the storage emulator and running again the app.(F5) everything should be fine.
I've seen this happen before as well.
However, there is a way around it. You can edit the ServiceConfiguration.cscfg for your web role and set the instance count to 0. Then set your actual web application as the startup project instead of the Azure Web Role. This will allow you to use Cassini / IIS Express instead of the Compute Emulator to develop your web application.
NOTE: When you do a deployment you will have to set the instance count to something greater than one.
<ServiceConfiguration serviceName="Web" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration" osFamily="2" osVersion="*">
<Role name="WebRole1">
<Instances count="0" />
<ConfigurationSettings>
<Setting name="LogLevel" value="Error" />
</ConfigurationSettings>
</Role>
</ServiceConfiguration>
ALSO NOTE: There are certain features you will not be able to test when running your site like this. One example is local storage. If you're using features like that in your application you can simply switch the configuration and startup project back.
You'll also notice a huge speed increase when you press F5 to debug your application.
I've seen this happen with Chrome and Firefox. It doesn't happen with IE. Sorry I can't explain "why."
I'm trying to write an HttpModule to run on our SharePoint farm - essentially it will check whether the user is authenticated and if they are it will validate some info against another database and potentially redirect the user to sign a variety of usage agreements.
Whenever I enable the module in the web.config I'm finding that SharePoint has issues rendering the page - it's almost like the CSS is not getting loaded as the page is devoid of any styling.
As a test I've even tried an empty module - i.e. an empty init block so it's not even hooking up any code to any events and the same issue arises. At this point it's an empty class that just implements IHttpModule so it's not even my dodgy coding causing the issue!
The module is in a class library that I've dropped in to the bin folder of the application it needs to run against. In the web.config of the app I've simply added an entry as below:
<modules runAllManagedModulesForAllRequests="true">
... (default stuff ommitted)
<add name="SharePointAUP" type="SPModules.SharePointAUP" />
</modules>
I must be missing something really obvious here as I've done exactly the same as every sample I've found and yet I'm getting this strange behaviour. Is there something extra I need to do to get SharePoint to play nice with a custom module?
UPDATE:
In case it helps - this is SP 2010 beta running on Windows 2008 R2.
UPDATE:
The set-up I'm running against is a farm - 2 front end servers with NLB & 2 app servers with services split across them.
After listening to a nagging feeling this morning I've tested my handler on another installation we have which is a standalone set-up... and everything worked perfectly. The issue only exists when deploying to a farm.
make sure to include a precondition attribute
I came back to this after reinstalling the farm with the RTM - everything worked fine. I've written it off as beta issue (along with many others that I had with SharePoint if you've seen my other questions!).
I am trying to access a Windows Media Player library from ASP.NET.
The following code:
WMPLib.WindowsMediaPlayer mplayer = new WMPLib.WindowsMediaPlayer();
WMPLib.IWMPStringCollection list = mplayer.mediaCollection.getAttributeStringCollection("artist", "audio");
Returns an non-empty list when run using the VS2005 development web server but an empty list when using IIS.
Setting impersonation with:
System.Security.Principal.WindowsImpersonationContext impersonationContext = ((System.Security.Principal.WindowsIdentity)User.Identity).Impersonate();
Doesn't help. It seems that WMPLib still doesn't thinks its running as a user who has a library.
Is there a way to get around this?
Have you tried configuration via web.config in ASP.NET? When you're running in the VS2005 debugger, you're (probably) running code as yourself, but when under IIS you'll be running it as IUSR_machinename or another low-permission system account.
Try adding something like this to your web.config file:
<system.web>
<identity impersonate="true" userName="MYDOMAIN\myuser" password="p#ssw0rd" />
</system.web>
No idea whether this works with Media Player specifically, but it works for other identity/security related problems like this.
I've run into a similar problem: the code works fine on my local machine, but once deployed on my home server, it can not pull anything out of the media library (I can open media player to verify there are songs in the library)
At first I thought it was a process issue as well, so I tried both setting the application pool to run under my own account, and to set it via the identity impersonate tags; neither resolved the issue.
I'm not sure of what other differences would cause the issue