I want this line
<processor type="Estate.Packages.ModificationDate.SetModificationDate, Estate.Packages" />
beneath
<processor type="Sitecore.Pipelines.HttpRequest.ExecuteRequest, Sitecore.Kernel" />
in the web.config.
I tried to do this by adding a .config file in the app_config/include folder for the website.
<configuration http://www.sitecore.net/xmlconfig/">
<sitecore>
<pipelines>
<httpRequestBegin>
<processor x:after="*[#type='Sitecore.Pipelines.HttpRequest.ItemResolver, Sitecore.Kernel']" type="Sitecore.Packages.ModificationDate.SetModificationDate, Sitecore.Packages" />
</httpRequestBegin>
</pipelines>
</sitecore>
</configuration>
However, this ain't working. If I add the line in the web.config beneath the ExecuteRequest pipeline everything is working correctly. When I use the .config file nothing happens. (No error message either)
Anybody got a clue of what I'm doing wrong?
I suggest you to have a look at the Show Config tool (browse to http://yoursite/sitecore/admin/showconfig.aspx). It shows the final merged Sitecore configuration including all the pluggable configs out there. At least, it will give you a clue whether your injection is in the right place and in the right format. Later on you can play with the value of x:after attribute to find out what's wrong there.
From what I see, you mention you'd like to place your processor under ExecuteRequest, but your code references ItemResolver instead...
Related
Consider a group of developers working on an ASP.net web application. Each developer would like to have a private version of the web.config.
By "private" I mean that a developer can freely change the file to suit their dev/test needs at any given moment, without it affecting other team members and without ending up in source control.
How can one go about achieving this with Visual Studio 2015?
My closest solution so far is to have a "private" Solution Configuration with a matching Web.config Transformation file ("web.private.config") that's excluded from source control.
But this is not a satisfactory solution because:
a. The transformation is not run automatically when debugging (with F5). The developers need to remember to run it manually.
b. The result of the transformation ends up in the main "web.config" file which is, naturally, included in source control.
We had a very similar problem but only needed personalized versions of the <appSettings> section in Web.config.
In this situation the inclusion of an external file through configSource turned out to be problematic, as this attribute completely replaces the <appSettings>-node. So there remains no way to keep global key/values AND personal key/values for all developers. The whole section is completely replaced by the included private file.
What we need is both global and private <appSettings>. The solution we found was the file attribute. It allows to merge Web.config settings with settings from an additional file.
We ended up with a construct like this one:
<!-- Web.config with global appSettings) -->
...
<appSettings file="Web.PERSONAL.config">
<add key="BaseUrl" value="https://projectname.dev.local" />
...
</appSettings>
...
<!-- Web.PERSONAL.config with personal appSettings -->
<?xml version="1.0" encoding="utf-8"?>
<appSettings >
<add key="EmailSmtpUser" value="my.name#my.domain.com" />
<add key="EmailSmtpPwd" value="***" />
</appSettings >
If you put identical keys in both files, the Web.PERSONAL.config version will overwrite the Web.config version.
The file Web.PERSONAL.config must be excluded from Git through .gitignore .
Keep in mind:
While configSource works for ALL nodes in Web.config, the file attribute is restricted to <appSettings>.
Have web.config include an external file (via configSource) and add that file to .gitignore
The correct answer is to host your local development site in a separate location from your Visual Studio solution. You can then use publish profiles to publish changes to that location and web.config transforms to maintain a separate local config for each developer. Each developer would use a different publish profile which transforms the web.config with their own transform and deploys the transformed web.config to the publish location. You can then attach a debugger to the published site using Visual Studio's Debug > Attach To Process option.
I think there is a lot of value in standardising dev environments so that one can just download the solution and run it.
Custom, long term/permanent, developer specific configs will sooner or later lead to a subtle bug that will be tricky to find.
My solution to your problem would be to find out the reason(s) why permanent individual configs are needed and have a look if these environment specific differences can be eliminated.
This is the error I'm receiving when trying to load CSS/less data:
I looked around StackOverflow for the same problem and I find out that I had to use an absolute URL for the stylesheets. I tried basically every combination of the URL where my stylesheets are located, but I still get the same error but only different link attached.
The stylesheets that I need to render are located in /client/stylesheets/less, but no matter what URL path I type, i get the same MIME/type error.
Can anyone be kind enough to point a fellow in the right direction?
Make sure the .css and .less extension are set up to use text/css as the MIME Type either on the server level or for your web application. You can add this MIME type to your web.config if you do not have access to the server level configuration.
<system.webServer>
<staticContent>
<remove fileExtension=".less" />
<mimeMap fileExtension=".less" mimeType="text/css" />
</staticContent>
</system.webServer>
The remove is included for if the setting is configured at the server level already to not cause a conflict.
Did you forget to install the less compiler?
meteor add less
This should be a simple one. I am using a program that has themes defined in its Web.config file. I want to turn these off for a subdirectory.
I copied Web.config into a subdirectory and tried removing the theme attribute from the pages element on Web.config but that didn't get me anywhere. I got a bunch of errors about elements that are apparently not allowed in non-root Web.config files so I removed all of those elements, but I am still getting the same error.
I tried adding EnableTheming="False" in the ASPX Page header, the thing that defines Language=C#, etc., but it didn't work either.
So if someone can tell me a tested, confirmed way to make this work, I would appreciate that. I am using .NET Framework 2.0 on Server 2003.
Got it with a very basic Web.config:
<?xml version="1.0"?>
<configuration>
<system.web>
<pages theme="" />
</system.web>
</configuration>
if it is cached, what happens if I use multiple web.config in multi-level folders
They all get cached.
Configuration is read once, at startup. With web.config, IIS watches for file changes and restarts the application.
OK, so ya'll are missing a KEY feature in the Web.Config file's area.
Yes, web.config is cached and changing contents of the file will restart your web app. And, all your connected users will not be happy, too, because they'll need to "reconnect" a-new, possibly losing desired information.
So, use an EXTERNAL custom file for your AppSettings, as follows:
<appSettings configSource="MyCustom_AppSettings.config"/>
Then, in the file MyCustom_AppSettings.config file, you have your settings, as such this example has:
<appSettings>
<!-- AppSecurity Settings -->
<add key="AppStatus_Active" value="Active"/>
<!-- Application Info Settings -->
<add key="AppID" value="25"/>
<add key="AppName" value="MyCoolApp"/>
<add key="AppVersion" value="20120307_162344"/>
</appSettings>
Now, if you need to add, change, or remove an AppSetting, when you change it in this file the change is nearly instant in your web-app BUT (and here's the BEST part), your app DOES NOT RESTART!
Everything stays kosher except those settings you've added/modified/removed in the external .config file.
And, yes, the same thing can done for the section as follows:
<connectionStrings configSource="MyCustomApp_ConnectionStrings.config"/>
and the file MyCustomApp_ConnectionStrings.config has all the connection strings you need. Change a connection string in the external .config file and it starts getting used right away and with no web-app restart.
The configSource setting(s) are great when you need to deploy to development, testing, and production on different boxes and need settings pertinent to that given box/environment.
So, now ya know (something that's been around for 7+ years).
It's That Simple. Really.
KC
Web.config (excluding external config files) is read when the application loads. Some config settings have a cascading behavior. For example, the system.web/authorization section can be overridden by configs at deeper levels.
ASP.NET monitors the web.config for changes. When it changes, the web application is forced to restart. Moral is that web.config settings are cached for the life of the application.
I am developing a asp.net project and I dont have very long web.config file yet(more then 400 lines). but with this nhibernate log4net and urlrewrites. its getting bigger and bigger. is there a proper way to divide web.config into pieces. like nhibernate.config and log4net.config ofcourse urlrewrite.config
system.webServer is a configuration section group - you cannot externalize that.
You can only put the configSource= on a configuration section - e.g.
<system.webServer>
<validation configSource="validation.config"/>
<modules configSource="modules.config" />
<handlers configSource="handlers.config" />
</system.webServer>
What is a configuration section group or a regular configuration section can only be determined by looking at the documentation for those things (and even then it's often not very easy to figure out whether it's a section or a section group :-( ).
This is possible by using the configSource attribute of root sections in the config file. This is actually a feature of the .NET configuration system so it can be done in any web or app config file.
Here is a blog post that describes this feature quite well.