I notice that there's frequently an aspnet_client folder under the standard IIS web folder structure. What is this used for? Is it needed?
In the .NET 1.1 days and before, this folder provided ASP.NET with its JavaScript support for the validation controls and other functionality. If you don't have a .NET 1.1 site or older running it should be safe to delete it. I would rename it first to ensure it doesn't cause any problems.
In addition to what others have said, it's usually created by the aspnet_regiis tool, which can be (re-)run by things like Windows Update/AddRemove Windows components/IIS. So sometimes even if you do delete it, it can come back randomly. There may be a way to stop this behavior, but I haven't found it (maybe changing the application version to .NET 2 would do it actually).
So unless you're using certain features of .NET 1.0/1.1 (validation, Smart Navigation etc) you can delete it without any problems, just don't be too surprised if it comes back!
aspnet_client is a folder for "resources which must be served via HTTP, but are installed on a per-server basis, rather than a per-application basis".
Some of the uses of aspnet_client include storing resources (eg. JavaScript, images) for:
JavaScript for ASP.NET Web Forms controls when using client-side validation (mainly to manhandle older browsers like IE5, it seems)
ASP.NET 2.0 (until at framework 4.0) for 'Global Themes' (global to all sites on a server, that is)
some versions of Crystal Reports
There probably are/will-be further (ab)uses of this folder in the future. Needless to say, since it contains things which are "necessary for the application to run correctly" but which "are not supposed to be deployed by the application", it will remain something of a nightmare for both developers and system administrators.
It seems that the 'prototype' for the contents of the folder is in C:\inetpub\wwwroot, and it seems reasonable to suppose that if any given IIS website lacks a /aspnet_client resource, then IIS will try to do the right thing and ... as a last resort ... make a physical folder in the web site root folder, and copy the files there. It seems that IIS will do this at least when "ASPNET_regiis /c" is invoked a given server - which probably occurs automatically at some critical junctures ... like when .NET framework updates are applied to a server which has the IIS role.
Strategies for handling the aspnet_client directory include:
specifying a virtual directory mapped to C:\inetpub\wwwroot in the hope that IIS will forgo creating a physical directory
deleting the physical directory from time to time if you're sure your site doesn't need it and it really bothers you
ignoring aspnet_client
running "ASPNET_regiis /c" yourself if you're missing the folder, and need it
Probably most importantly, as a developer, you should clearly understand and document your applications' dependencies on the aspnet_client directory, and make sure that your installation procedure has relevant instructions for making sure that the directory exists. However, you should probably not bother to actually supply the directory as part of your packaged web application or web site - how could you possibly do this for each version of the .NET framework which the server will see over the lifetime of your application?!
Some links I will come back to later:
http://my.safaribooksonline.com/book/certification/mcts/9780735657489/2dot-using-master-pages-themes-and-caching/ch02s03_html?query=((aspnet_client))&reader=html&imagepage=#snippet
What is the aspnet_client folder in my ASP.NET website?
iis express path for global theme directory
http://my.safaribooksonline.com/book/web-development/microsoft-aspdotnet/0735621772/aspdotnet-configuration/111?query=((aspnet_client))#X2ludGVybmFsX0J2ZGVwRmxhc2hSZWFkZXI/eG1saWQ9MDczNTYyMTc3Mi8xMTE=
http://my.safaribooksonline.com/book/web-development/microsoft-aspdotnet/9780471785989/working-with-themes/ch41lev1sec8?query=((aspnet_client))&reader=html&imagepage=#X2ludGVybmFsX0h0bWxWaWV3P3htbGlkPTk3ODA0NzE3ODU5ODklMkZjaDQxbGV2MnNlYzEwJnF1ZXJ5PSgoYXNwbmV0X2NsaWVudCkp
http://my.safaribooksonline.com/book/web-development/microsoft-aspdotnet/067232542x/performing-form-validation-with-validation-controls/ch03lev1sec1?query=((aspnet_client))&reader=html&imagepage=#snippet
http://scn.sap.com/thread/3157366
It also has certain icons and scripts that are required for crystal reports to run properly even in versions later than 1.1
The folder is usually for storing client side Javascript, which ASP.NET uses for things like validation.
It should be safe to delete.
Figured I'd add this here as this is the link I kept being directed to when I googled this question. Apparently with .NET 4.0 and newer this folder is no longer needed and can be removed without issue.
If you are using Installshield to configure ASP.net website, be aware that this feature was present in Installshield 2010 and is missing in Installshield 2012.
Related
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 have set two websites in my IIS 8.5. I have one for production version and one for development (need this for the team work purposes). The structure is simple. Website is simple static page using BackboneJS and API calls to get all the data. All virtual paths and applications were set at the beginning manually by my self. For some reason some API calls didn't worked in dev site. I found out the physical path to the API project has changed. Do you have any idea, where can be the problem? Actually some of my collegues face this issue too.
Only think that cames to my mind is that when bdebugging the API, I use "Attach to process" in Visual Studio, where I connect to the correct IIS process - w3wp.exe with user name IIS APPPOOL\Dev or IIS APPPOOL\Prod according to the site I'm debugging.
Nevertheless I don't think the path should change itself. Where can be the problem? Does anyone have any idea how to prevent this strange behaviour?
I have a web application project in VS2012 which I'm publishing using a "Web Deploy Package". I want this package to include app-pool settings, specifically creating an IIS app-pool and assigning the newly created application to it.
I'm familiar with the option "Include application pool settings used by this Web project" available when the project is configured to use an IIS instance (not IIS Express), but IIS configuration is not part of the project file, and thus not source controlled. What happens when somebody builds a deployment package on a machine that hasn't had IIS meticulously configured? Not ideal.
How else then, can I go about getting AppPool settings into my web deploy package? I understand that the appPoolConfig provider is IIS7+ only, I'm fine with that limitation. I've banged my head against this issue in the past and never found a solution. 18 months later, we've got a new VisualStudio version, and a new web-publishing-pipeline, are there new options to address this? Or maybe something I missed when I first tackled this problem?
Edit
OK, I'm seeing the following as options:
Configure my project to sync settings from an IIS instance. As mentioned, I'm not a fan of this given that it puts settings outside of the project, meaning the environment has to be meticulously configured to build + publish. Plus it drags along other IIS settings I don't want included.
Inject something into the web-publishing-pipeline (WPP) to modify the archive.xml. I've toyed with this in the past and had limited success. One problem is the pipeline isn't exactly co-operative with working directly on the archive.xml file, another problem is some of the more cryptic attributes involved, like MSDeploy.MSDeployProviderOptions which appears to have some Base64 encoded binary? No idea what to put in there.
Find an existing "provider" that can do what I want. I might be out of luck here, the appPoolConfig provider only seems to want to read / write IIS, not, say, an XML file of settings. Does anybody know otherwise?
Write my own "provider" to produce manifest output entries. I'm not sure, is it possible to write a custom provider that writes to a manifest using the name of an existing provider? As in, MyCustomPoolProvider writes appPoolConfig sections into a manifest? This sounds like a potentially painful exercise that may or may not work. Would I still need to figure out the encoding of whatever is going into MSDeploy.MSDeployProviderOptions?
I get the feeling that the fundamental obstacle with Web Deploy for what I'm trying to accomplish, is how strictly it leans on "providers". The pre-existing providers are largely designed for IIS synchronisation, not primary development and publication. It so happens that some of these providers can be relatively easily hooked into via MSBuild, but the majority insist on pulling data from IIS, and that's that.
You are correct in your understanding of the appPoolConfig provider, in that it can only sync between App Pools and can't be provided with the configuration directly. What you could potentially do is keep a copy of the appPool in question in package form (ie. msdeploy -verb:sync -source:appPoolConfig=PoolName -dest:package=apppool.zip) and attempt to hijack the pipeline so that the MSDeploy call adds the application content into the package, leaving the existing content there.
Alternatively, you could always keep the packages separate and deploy them with different calls to MSDeploy.
FYI, MSDeploy.MSDeployProviderOptions is simply an encoded version of the parameters supplied to the provider when it was packaged. For example, -source:dirPath=c:\,ignoreErrors=0x10293847 -dest:package=package.zip would package the ignoreErrors value.
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
I'm running into a problem setting up my development environment. I've been working on ColdFusion and .NET applications up until recently I haven't needed to touch IIS. Now, I have to set up a classic ASP application for some one-off work.
I added a virtual directory in IIS and pointed it at the actual codebase on my local machine. I then set the security to low (for ISAPI extensions, i.e. ASP) and allowed for script execution. For some reason though, if I hit any .asp page it says the page cannot be found. However, HTML and static files load up just fine.
EDIT: URLScan fix seems to have done it. Fired up the app in another browser (i.e. not IE6), and I'm getting better error reporting. Looks like we're missing some includes, but it is executing the scripts. Thanks!
You need to make sure that the "Active Server Pages" web service extension is set to an allowed status.
Check out: http://classicasp.aspfaq.com/general/why-does-iis-hang-and/or-stop-serving-asp-pages.html
Also, you should be aware that a virtual directory may affect the include file paths in the asp pages themselves. If the original asp application does not use a virtual directory, then your local copy shouldn't either.
Take a look at your URL scan settings and see if .asp is an allowed file extension
On my XP machine the relevant file is located at C:\WINDOWS\system32\inetsrv\urlscan\urlscan.ini