I'm doing research for an article on the ASP.NET Pipeline, but none of the resources I've covered so far adequately explain when the machine level, and application level, and possibly even sub-application level, web.config files are read.
Also, most of my reading has mislead me to look for default HTTP handlers etc. in machine.config, which seems to, at some point, have been mysteriously replaced by a web.config at the machine level, i.e. in the same config framework folder as machine.config. Are that many articles etc. so out of date, or was this a very recent change? Or, may I be imaginative and consider that the machine level web.config actually 'inherits' from machine.config?
The most comprehensive description of how asp.net configration files work that I know of is this one at MSDN:
ASP.NET Configuration File Hierarchy and Inheritance
It is written for the .NET 3.5 framework so the info should be as current as you'll likely find. It describes exactly how the various configuration files are read and merged into the runtime settings for the application in quite a lot of detail.
ASP.NET config files work in a hierarchical manner (much the same way as CSS elements).
Configuration Inheritance
Related
I'm trying to implement ASP.Net FormsAuthentication across many applications. I have already got a working prototype of this that shares the same login in couple of applications. As described here, the applications need to share some settings for this to work, for example the machinekey-section:
<machineKey validationKey="C50B3C89CB21F4F1422FF158A5B42D0E8DB8CB5CDA1742572A487D9401E3400267682B202B746511891C1BAF47F8D25C07F6C39A104696DB51F17C529AD3CABE"
decryptionKey="8A9BE8FD67AF6979E7D20198CFEA50DD3D3799C77AF2B72F"
validation="SHA1" />
I would like to have these settings in one place and use them in all of the applications. It would not make sense to have the same settings in 10 applications. If I want to change a setting, I want to do it in one place and have all the applications to use that afterwards.
Is it possible to have these settings for example in a class library project which the other applications use? How would you implement this? I tried the configSource-attribute, but I think I cannot use it with a config-file inside the class library. Am I right?
What other approaches have you used? All comments are welcome. Thanks!
The best solution would be to define it in your web.config and include it in your deploy packages. Therefore, when you deploy a new version with modified web.config, the changes will be deployed everywhere.
You can also use the xml transforms (http://msdn.microsoft.com/en-us/library/dd465326.aspx) to ease the management of these settings (debug and production settings may be different). You can then use a different project configuration (and therefore, web.config settings) for each publish profiles.
The main advantage is that the whole process is then automated, less error-prone.
Is it good practice to have a production (live) asp.net website that is also a working copy to push updates?
In general this is considered bad practice primarily because the source control repository contains the source whereas the production application contains the result. The two are kept separate for a number of reasons:
Security. If your source is on your production server, it's at risk of being viewed. Maybe this is a problem, maybe it's not. The safe approach is to just not have the source on the production server.
Performance. The result of building the source can be optimized for performance in ways that the source itself generally isn't. In a .NET application, for example, the production deployment doesn't contain debugging symbols. This may not be an issue in your particular application, but it's something to consider.
Multiple Results. Is your source an actual application, or is it information used to build an application? Can multiple versions be built? For example, in a .NET web application, you might have Web.config transforms. These are used at deploy-time to adjust the result of building the source. If the source itself is being used as the live application, these deploy-time modifications aren't available.
Others may be able to articulate this much better than I can, but in general it is considered bad practice, yes. Your particular application may be an exception to any particular reason or may not be meaningfully affected by any particular reason, so I stress the "in general" part.
Depending on the layout of your project, there may be some security concerns. For instance, if you have a .txt file with some sensitive information, keep in mind that it will accessible in your site.
Anything in App_Code or any .cs, .vb, .config, etc files will not be served by ASP.NET, so you can put stuff you don't want people seeing there.
Also, for initial loading performance, you should precompile your site via the VS Publish command or the Web Deployment Project addin (assuming you're working with a web site project). You could create an svn branch for the precompiled, deployable code and use that branch on your server.
You can use services like http://springloops.io or http://deployhq.com to only push certain folders to a server. That gives you a lot of flexibility in pushing code to deployment.
I modify web.config when I HAVE TO :-) Debugging setting, session state setting, etc. But in those cases, some tutorial or error message has been explicit: "Open web.config and do XYZ".
What I wonder is, what else can it do? What things that I do now in other ways would be better done in web.config. Is there a good primer or even a comprehensive web.config book or other resource that I can study to get good understanding of what it is really capable of?
I've searched for "web.config" on amazon, etc., and lots of returns for specific technologies that use it, but nothing focused solely on web.config itself.
I hope this isn't a really dumb question.
check the below links...
ASP.NET Configuration
Format of ASP.NET Configuration Files
Web.config Tutorial ASP.Net 2.0 & 3.5
ASP.NET Tutorial: Web.Config
Managing Multiple Configuration File Environments with Pre-Build Events
The ASP.NET Web.config File Demystified
I would start with MSDN
http://articles.sitepoint.com/article/web-config-file-demystified
Scott Hanselman has some good postings too:
http://www.hanselman.com/blog/ManagingMultipleConfigurationFileEnvironmentsWithPreBuildEvents.aspx
I'm really interested in gaining an in-depth understanding of the format and structure of the web.config file for ASP.NET web development. I'd like to know if there's some really easy to comprehend material (apart from the MSDN docs) which can provide me a ground-up understanding of the web.config file and its different sections.
Any suggestions?
This is a really good article:
The Web.Config Demystified
It takes the magic out of the Web.Config... which after all is just an XML file.
Best Practices on using App Settings and Connection Strings
Another link about putting AppSettings in a separate File. I do this ALL THE TIME. I'll have several files where my test environment are different and have something like:
Conn.test.Config
Conn.test.Config
App.test.Config
App.live.Config
Here's MSDN docs which outline the additions for .Net 3.5.
AND... one GREAT way of finding out what people have found to be useful is the items tagged Web.Config in delicious
I also love showing people that the fancy "website configuration" under the ASP.Net Tab in IIS is just parsing an XML file and there's nothing fancy about it.
Disclaimer: I have limited ASP.Net skills
I have a couple of websites which I am transferring from my current hosting onto the Mosso hosting service. When I tried transferring one of the websites, I got the error "System.Security.SecurityException: That assembly does not allow partially trusted callers.", which appears to have to do with the fact that Mosso runs on Medium Trust for ASP.Net apps, and the code in the website appears to require full-trust.
Unfortunately, I don't have access to the full source code for the app, and the original developer is not available. Is there any easy workaround to porting these websites? I tried adding in web.config but that didn't work.
I don't think asking Mosso to adjust the security level is an option, because they had refused when I asked them.
Does anybody have any ideas?
Is your assembly strong named? Does it call strong named assemblies?
You should apply the 'AllowPartiallyTrustedCallers` attribute to the Assembly. More information about this attribute is available here.
From the docs:
By default, a strong-named assembly
that does not explicitly apply this
attribute at assembly level to allow
its use by partially trusted code can
be called only by other assemblies
that are granted full trust by
security policy. This restriction is
enforced by placing a LinkDemand for
FullTrust on every public or protected
method on every publicly accessible
class in the assembly. Assemblies that
are intended to be called by partially
trusted code can declare their intent
through the use of the
AllowPartiallyTrustedCallersAttribute.
See this MSDN article for more information.
Edit:
Some information that confirms my suspicions that the APTCA attribute is a possible solution to the problem:
https://support.isqsolutions.com/article.aspx?id=10334
http://bloggingabout.net/blogs/rick/archive/2006/04/07/11929.aspx
Sorry to say but unless they allow you to set the trust level, you could have big issues. You could have a look here.
Professional ASP.NET 2.0 Security, Membership, and Role Management
Almost exactly the same thing happened to me, except the my hosting company changed their trust policy after I a number of websites running on their servers for a couple of years. In the end I had to give up and move to DiscountASP as they overrode <trust level="Full" /> in my congfig file.
Here was my original question.
ASP.NET WebPermission Security Exception
Good luck
I know this is old, but I thought I'd add something to it that might help. Mosso's change to Medium trust caused us some issues as well.
We use BlogEngine.NET and access MySQL for its backend. We had the MySQL dll in our bin directory and that was causing issues with medium trust. Once Mosso added a MySQL dll to the GAC, we were able to use it successfully.
Obviously, I don't know your particular details and what you are trying to do, but if it is related to MySQL, let me know.