Good Day,
I am running into an error that I have never run into before. I have a brand new server (Windows 2016) and I have added IIS 10 to it. I have also installed .net Core 2.1 and 2.2 runtime and SDKs onto the server. When I set up a .net Core 2.1 website, it appears to set up fine, but when I try to click on any of the features in the features view, I get a really generic error message (it happens for any .net Core website I set up). The error is an alert that states: There was an error while performing this operation. Details: [empty] Filename: \\?\D:\Apps\Test\web.config Error: [empty]
I found one place where this question was asked before, but I have IIS Rewrite 2.1, .net Core 2.1 and 2.2 and I have this site set up on another server (test env) and it works perfectly fine there! I have also made sure that IUSR and IIS_User both have read/write capabilities to the folder and every file in it.
Does anyone have any suggestions?
Thank you,
Tim
In my experience, this sort of error normally means there is either something it doesn't like in the web.config (XML element it doesn't recognize) or the web.config is missing.
Normally (for me anyway) this is because I've forgotten to install URL Rewrite as that's pretty much the only "extra" thing I use - but you've got that covered already.
It might be worth checking that the App Pool for the site is configured correctly and running (should be same as your other machine, check the basic settings and the advanced).
The only other thing I can think of, is that you've installed some of the features for IIS through the Windows Features, but not all of them. I sometimes have to go back through the lists and make sure all the right things are definitely checked.
Last step would be to create a real simple little mini site, with just a default page, use the IIS GUI to change some site level settings so it creates its own web.config, make sure it runs, then have a look at the differences between the files.
Hope any of that helps
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!!!
I'm using SEO-friendly URLs, and I can process most of them with ASP.NET, by mapping aspnet_isapi.dll to all URLs. (I set up an Handler Mapping in IIS that uses the dll for all paths. (path = *))
However, that doesn't seem to work when the last character of a "subfolder" is a period. E.g., I have a URL of /brakes/A.B.S./, and that won't trigger the mapping. So I end up with 404s for such URLs. Does anybody know how I should setup the mapping to trigger this? (I've tried *. and that doesn't work either.)
Try changing this setting in your web.config:
<httpRuntime relaxedUrlToFileSystemMapping="true" />
http://haacked.com/archive/2010/04/29/allowing-reserved-filenames-in-URLs.aspx
As Matthew already pointed out, this is resolvable in .NET 4.0, but not in .NET 2.0. The problem lies in the underlying system: Microsoft forbids names to end with a dot (or a space, for that matter), because Windows Explorer cannot handle them (the underlying NTFS system can handle them, however).
What's the cause
Internally, and this is true for .NET 2.0 and .NET 4.0, a web request is passed, at some point, to the method IsSuspiciousPhysicalPath. Among other things, this method calls a standard API to create an "official" path based on the path given. It doesn't create this path. Then it compares this correct path with the given path. If they are different (i.e., if the given path does not exist in the corrected path) it is considered suspicious.
You can try this yourself: use File.CreateFile to create the file "test.txt....". This will succeed, but the resulting file is "test.txt". In the scenario above, the given file "text.txt...." does not fit the created file, hence it is suspicious and never even reaches the web request handler.
Even a 404-handler in the base IIS settings won't work here!
A far-fetched workaround
A workaround which I've used for years in many setups (for reasons not related to this issue): install Apache in front of IIS and configure it for proxying. That's relatively easy to setup (lost of examples on the internet) and this can act as a buffer for handling these kind of "illegal requests", rewriting them to something IIS can handle.
But it is probably easier to simply move from .NET 2.0 to .NET 4.0
I'm using Web API attribute routing
The selected answer did not work for me, it is only a partial solution.
to make sure the Web API gets the first crack at it, not only will you need to have
<configuration>
<system.web>
<httpRuntime relaxedUrlToFileSystemMapping="true"/>
</system.web>
</configuration>
you also need to have
<system.webServer>
<modules runAllManagedModulesForAllRequests="true"></modules>
</system.webServer>
I found the answer here at this blog:
ALLOW A DOT IN ASP.NET MVC APPLICATION (SPECIFICALLY IIS 7+)
In my case, I couldn't do it using the URL Rewrite while there was another reason which is the URL Scan.
I opened windows\system32\inetsrv\urlscan\urlscan.ini in a text editor and enabled AllowDotInPath by changing its value to 1
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