Is it possible to use appcmd to change the value of allowDefinition? Specifically I'm try to enable changes to the httpCompression module at the application level.
Modifying the applicationHost.config by manually changing the following line:
<section name="httpCompression" allowDefinition="AppHostOnly" overrideModeDefault="Deny" />
To
<section name="httpCompression" allowDefinition="MachineToApplication" overrideModeDefault="Allow" />
allows me to then execute the following appcmd commands:
appcmd set config "website name" /section:httpCompression /noCompressionForProxies:false
appcmd set config "website name" /section:httpCompression /noCompressionForHttp10:false
However I need a solution that does not rely on manually editing the applicationHost.config
My problem was, I had to change anonymousAuthentication from False to True. When I did:
appcmd set config websitename /section:anonymousAuthentication /enabled:True
Error I got:
Config Error This configuration cannot be used at this path. This happens when the section is locked at the parent level. Locking is either by default(overrideModeDefault="Deny")...
To unlock, do the following:
appcmd unlock config /section:? This will list the section you want. Then type:
appcmd unlock config /section:system.webserver/security/authentication/anonymousauthentication
Thats it... :)
Try using %windir%\system32\inetsrv\appcmd unlock config -section:*sectionName*. See http://blog.donnfelker.com/2007/03/26/iis-7-this-configuration-section-cannot-be-used-at-this-path/
I actually came across a need to do just that after posting this answer.
%systemroot%\System32\inetsrv\appcmd.exe unlock config /section:system.WebServer/[rest of the path to config section you need to edit]
One big warning, you should NEVER change the allowDefinition, that is an important setting that is usually there for a reason, for example it might be that even if you set it in a specific directory or app it will not work, so the developers have specified that.
So please, never modify the allowDefinition attribute in the section definitions. On the other hand you can modify the overrideModeDefault which will allow users to define it in a different place if allowed by definition.
Related
I have been trying hard to fix the issue in the web.config which doesn't allow me to host my site in the iis 8.5 - windows 2012 r2, throws this error which i have attached a screen shot.
I have no clue of what is going wrong here.
If some one could just shed some light, much appreciated.
Error message is pretty clear. Handler section is locked at parent or grand parent level. When section is locked at parent level you can not override it in child configuration.
Please check following web.config files at following locations.
Check if you have web.config file at location C:\intetpub\wwwroot. If its present check if you have following tag in web.config
<section name="handlers" overrideModeDefault="Deny" />
If its there then change it to
<section name="handlers" overrideModeDefault="Allow" />
If you don't find web.config in #1 above then open applicationHost.config located at path C:\Windows\System32\inetsrv\config
Check if you have handler section with overrideModeDefault="Deny" and if it is then change it to overrideModeDefault="Allow" as shown in #1.
Once you change it overrideModeDefault="Allow" then you can override it in child web.config
This seems like a relatively simple question, but I didn't see it clearly indicated in the documentation I examined. Assuming a typical Elmah usage on a Windows Server 2012/IIS 7 webserver installation, if the Elmah web.config settings are pointed to an Elmah.config file, will altering that file trigger under the running application cause IIS to restart?
While the answer provided by Josh would normally be true, it is not in the case of ELMAH. ELMAH instantiates a new error log implementation every time it is needed, reading the configuration from either web.config or the configSource provided.
You can do a simple test to prove this. If you configure ELMAH to use an external config file for the errorLog element like this:
<elmah>
<errorLog configSource="elmah.config"/>
</elmah>
and your elmah.config looks like this:
<?xml version="1.0" encoding="utf-8"?>
<errorLog type="Elmah.XmlFileErrorLog, Elmah" logPath="~/App_Data" />
When you start the project and force an error, a new XML file is written to the App_Data folder. Change the logPath like this (without restarting the application):
<?xml version="1.0" encoding="utf-8"?>
<errorLog type="Elmah.XmlFileErrorLog, Elmah" logPath="~/App_Data2" />
(I changed to App_Data2).
Force a new error and you will now see ELMAH create the App_Data2 folder on the file system.
No: Straight from MSDN:
Saving a Web.config file restarts the application. You can alternatively use the configSource attribute of individual section elements to point to a secondary configuration file that does not cause an application restart when it is changed. For more information, see configSource in General Attributes Inherited by Section Elements.
MSDN
has anyone successfully added IIS script maps to their Wix installation. I have been using this:
<CustomAction Id="AddHandlers_Cmd" Property="AddHandlers" Value=""[SystemFolder]inetsrv\appcmd" set config -section:system.webServer/handlers /+"[\[]name='GSOAP',path='*.dll', verb='*',modules='IsapiModule',scriptProcessor='[BIN]mod_gsoap.dll',resourceType='File', requireAccess='Execute'[\]]"" Execute="immediate"/>
<CustomAction Id="AddHandlers" BinaryKey="WixCA" DllEntry="CAQuietExec" Execute="deferred" Return="check" Impersonate="no"/>
However I get the 404 errors from my web application and when I add the script map manually after installing the application it works perfectly. I would appreciate if anyone could share how they done this.
It sounds like you need to add handler mapping to your web application. If that's the case, then you don't need a custom action to accomplish this.
Take a look at WebApplicationExtension element.
We are writing a separate Custom action in C# and Schedule it in after install Finalize to add handlers.
Try this, you can do anything with your own custom action.
I haven't worked with GSOAP handler, but used ASP.NET ISAPI extention. I suppose basically it has the same level of integration. I will post the code for ASP.NET and I hope you won't have problem with changing it to GSOAP. I have a huge risk of changing something incorrectly and make the examples unusable for you, so I let you do it better.
Here is my code to register extention itself if it isn't
<Component Id="Iis6ConfigExtentions" Guid="{GuidHash({ProductId}-1822E4F3-5850-47D5-9281-D1E0E20C77D4)}" KeyPath="yes" Permanent="yes">
<Condition><![CDATA[Installed OR (IISMAJORVERSION AND (IISMAJORVERSION = "#6"))]]></Condition>
<iis:WebServiceExtension Id="ExtensionASP4" Group="ASP.NET v4.0.30319" Allow="yes" File="[FRAMEWORKROOT]v4.0.30319\aspnet_isapi.dll" Description="ASP.NET v4.0.30319"/>
</Component>
and for adding those to the concrete site you need to use WebApplicationExtention, as #Yan already mentioned:
<iis:WebApplication Id="IIS6WebApp" Name="[SITE_APP_NAME]" WebAppPool="AppPool" >
<iis:WebApplicationExtension Verbs="GET,HEAD,POST" CheckPath="no" Script="yes" Executable="[FRAMEWORKROOT]v4.0.30319\aspnet_isapi.dll" />
</iis:WebApplication>
The CheckPath="no" is required on IIS 6 because we use ASP.NET MVC which doesn't map urls to files on disk. You might need it too since service address probably doesn't map to physical file.
UPDATE:
Looks like it is really not possible to do it directly in WIX (at least in 3.5 version). You are going in right direction - custom action using appcmd. But the provided custom actions aren't complete or what you need: the first one just sets property value to the command you need to execute and the second one calls some Dll custom action which wasn't provided.
What I'd try to execute is:
<CustomAction Id="AddGsoapHandler" Directory="TARGETDIR" Impersonate="no" Execute="deferred" Return="check" ExeCommand="[SystemFolder]inetsrv\appcmd.exe set config -section:system.webServer/handlers /+"[\[]name='GSOAP',path='*.dll', verb='*',modules='IsapiModule',scriptProcessor='[BIN]mod_gsoap.dll',resourceType='File', requireAccess='Execute'[\]]" /commit:apphost" />
Please pay attention to the path attribute of your handler configuration. It will limit handler usage to only URL's which ends with ".dll" - I just copied it from your code but not sure if you've done it intentionally or just copied from example at Microsoft site. That might have led to 401 error even if handler is registered successfully.
Also I added the /commit:apphost argument. Not sure if you really need this, but I use it to explicitly specify that I need to configure my application's config.
UPDATE 2:
If you need to set configuration to only single application, you should specify application object as argument of appcmd instead of the 'config' which means global configuration. Please try this:
<CustomAction Id="AddGsoapHandler" Directory="TARGETDIR" Impersonate="no" Execute="deferred" Return="check" ExeCommand="[SystemFolder]inetsrv\appcmd.exe set app "MySite/app1" -section:system.webServer/handlers /+"[\[]name='GSOAP',path='*.dll', verb='*',modules='IsapiModule',scriptProcessor='[BIN]mod_gsoap.dll',resourceType='File', requireAccess='Execute'[\]]" /commit:apphost" />
For more details you can read this tutorial.
I have Sitecore as site root (which is running ok) and under it I need to have a bunch of asp.net applications running.
So far, created a virtual directory for the child application, turned it into an app. But as soon as I browse the child app it comes with this error message.
Compilation Error
Description: An error occurred during the compilation of a resource required to service this request. Please review the following specific error details and modify your source code appropriately.
Compiler Error Message: CS0246: The type or namespace name 'Sitecore' could not be found (are you missing a using directive or an assembly reference?)
Source Error:
Line 3264: </providers>
Line 3265: </roleManager>
Line 3266: <profile defaultProvider="sql" enabled="true" inherits="Sitecore.Security.UserProfile, Sitecore.Kernel">
Line 3267: <providers>
Line 3268: <clear/>
It seems that the child asp.net app is inheriting Sitecore settings which are coming from Sitecore web.config.
Any ideas?
This should be possible. You'll have to author a web.config for that non-Sitecore application in virtual directory, and overwrite the sections under <system.web> and <system.webserver> which reference Sitecore classes. This includes:
httpModules / httpHandlers (for these you should "remove all" and add those of that web app)
security section (put the default ASP.NET provider classes back)
in Sitecore main web.config add the path of this web app to IgnoreUrlPrefixes setting to let Sitecore know it should not handle requests to those
It might be something else, but you should get the general idea.
This answer is similar to Yan, but is different enough for a separate answer. Hope it helps.
Go into IIS and select the Child Application. Select Modules. Remove all the Sitecore related modules that are present. Don't worry, the parent Sitecore app will still retain these modules.
When you do this, you are actually changing the child app web.config, so you will see the elements removed in the web.config file like so.
<remove name="SitecoreConfigWatcher" />
<remove name="SitecoreHttpModule" />
You also may have to clear out some other inherited settings.
<profile enabled="false"><providers><clear/></providers></profile>
<roleManager enabled="false"><providers><clear /></providers></roleManager>
I am using log4net during my development, as as part of a project constraint, I now need to add it to the Global Assembly Cache.
The logging definitions are in a file Log4Net.xml. That file is referenced in my assemblyinfo as: [assembly: log4net.Config.XmlConfigurator(ConfigFile = "Log4Net.xml", Watch = true)]. So long as the xml file was in the same directory as the log4net.dll, everything has been working fine.
However now that I've added log4net to the GAC, it is no longer picking up the xml file.
Does anyone know what I need to change in order to have it pick up the XML file again? Is hardcoding the patch in the assembly reference the only way?
Many thanks
log4net expects the config file to be in the path returned by:
System.AppDomain.CurrentDomain.BaseDirectory
Let your application print this information to some file and then you know where you need to place the config file.
Of course there are other solutions, but then you cannot use the attribute anymore. Calling the ConfigureAndWatch() method directly allows you to figure out yourself where the config file is; you can even decide on a location (does not have to be a hard-coded path).
You might ensure that your log4net.xml file is set to "Copy Always" (Right Click on log4net.xml -> Properties -> Copy to Output Directory = Copy always). To ensure that your config file is being copied, you should check your bin\debug or bin\release directory and verify that the log4net.xml file exists in the same directory that your application executes.
If that doesn't workthen you can try enabling internal debugging in log4net. To enable internal debugging, add the following key to your app.config file. This will send internal log4net debug messages to your Visual Studio Output window (View -> Output).
<configuration>
<appSettings>
<add key="log4net.Internal.Debug" value="true"/>
</appSettings>
</configuration>
For more information on log4net's internal debugging, you might check Phil Haack's blog post here.
If all else fails, you can turn on internal debugging and explicitly load the configuration by calling log4net's XmlConfigurator.ConfigureAndWatch method.
var fi = new FileInfo(Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location) + "\\log4net.xml");
XmlConfigurator.ConfigureAndWatch(fi);