I understand that I can add the following to the web.config file:
<httpRuntime maxRequestLength="10096" executionTimeout="120"/>
This will increase the upload limit for the application. The problem is that the WEB.CONFIG file is part of the application and part of my installation. I have multiple customers with different values they want to use. The Web.config file is overwritten each time they install a new version of my application. Thus, this would overwrite any modifications to the upload size they might have made.
Currently I have my customers change the Machine.Config file, but this is really not the best solution as they are changing the parameters for the whole IIS Server.
I figured maybe I could have the customer add an App.Config to the folder, where they could set their own parameters. Since that file is not part of my installation, it would stay.
Has anyone else had this problem, figured out a way to work around having the customer have an ability to have their own custom config file that will not get overwritten when they install a new version of the application?
Thanks,
Cory
In web.config:
<httpRuntime configSource="httpRuntime.config"/>
In httpRuntime.config:
<httpRuntime maxRequestLength="10096" executionTimeout="120"/>
See the configSource attribute in General Attributes Inherited by Section Elements and SectionInformation.ConfigSource Property on MSDN for an explanation.
Related
I have a web application that we publish and provide for users to install and run on their local network. They choose whether they run it as an internet, or intranet application.
When we publish the application we label the folder with the publish date (e.g. 20140815) so we know which version they have. However, when they contact support, it is a pain for them to get on the server to see the folder information.
I want to add an appsetting for cloudVersion and display it on the license page so they can easily provide it from wherever if needed. Also, they feel better seeing the version increase so they know they are getting value with the service contract.
<add key="cloudVersion" value="20140815"/>
I would like to automate the version in the appsettings. I was hoping I could use a Web.Config transform to set it with a dynamic yyyymmdd, but can't see how to do that and have found nothing in my web search.
<appSettings>
<add key="cloudVersion" value="GETDATE()" xdt:Transform="Replace" xdt:Locator="Match(key)"/>
</appSettings>
Is this possible? If so, how? If not, is there a better approach to achieve the same result?
Short of finding a great solution for this, I have elected for the following:
After publication, I run a bat file that does the following:
copy the published directory and rename with today's date
update the Web.Config appSetting value
compress the updated directory using 7zip
upload the compressed directory to Google Drive so my support team can provide it to our users.
You can see how I modified the string here:
bat file to modify web.config setting
I have upload functionality in my application. I was facing an upload issue and found out that in Web.Config there is httpRuntime tag. I set the change as below.
<httpRuntime requestValidationMode="2.0" maxRequestLength="2147483647" />
This fixed my upload issue. The above is my Web.Config in my root folder, one that we get by default.
Questions.
Can I create a seperate Web.config file? If Yes, I have to upload the files in some other Virtual Directory and my code is in some other project. So where shall i place the Web.Config file ?
Is it possible to set these settings at page level?
You can add a web.config file to nearly any folder (I doubt the app_data would allow it (but I could be wrong, however this is beside the point)).
You can of course (if possible) create many folders for each setting you need. In other words, have 1 file per folder to get around your issue.
Or, create a new parent folder which you want all sub folders to 'inherit' your new web.config file from. Your web.config file goes into this new parent folder.
Remember, the web.config file inherits from the parent web.config file, so you don't need to write the entire configuration again, just the section you want to add/overwrite.
As we know there are some config setting we can make to web.config file like mentioned at link
Now as a beginner i need to know what else we can do with this file/ i.e what else we can configure with this file in ASP.NET MVC2,3?
You can configure many other items in the web.config. However this question is not direct enough to provide an answer.
You can see the entire schema here
Web.Config is not limited to any application. Web.config can work verymuch in same way for any applications. Along with the mentioned details we can include a bunch of sections into Web.Config. some of them includes
1) If you are using any services, then service end points you can define in web.config.
2) Error/Exception handling configuraton you can define.
3) if you will use Unity, you can define Register types in config.
4) Any IIS configuratons, can overridden in web.config.
5) Any IIS Error page setup.
This might be a borderline Server Fault-question, but here goes.
I have a IIS 6 where AspMaxRequestEntityAllowed="204800" in MetBase.xml, suggesting the upload file limit is 200kb, while <httpRuntime maxRequestLength="20192"/> in web.config allows for a 20mb upload - and the latter is what the application allows.
Why do web.config override MetaBase.xml? To me, that seems like an error of hirarchy. And where would I find a "centralized parameter" to config max limits for the entire machine the server is on, in case I don't want some web.config mishapp to allow for gigabytes of upload?
Web.config file is the last-point configuration manager and entries in it will override any entries made in the higher layers.
I.e. any settings made in machine.config file (which are applicable to all websites) will be overridden by web.config (applicable to only that website).
In fact you can have separate web.config file for each folder which will override your root level web.config.
This is the way hierarchy works you know.
I am not aware of MetaBase.xml but in your machine there are default configs available in folder
c:\Windows\Microsoft.Net\Frameworks\VERSION\Config
am sorry the exact name could be little different, but you will figure out easily, here you will find couple of different web.*.config files, in each of them you can configure and there is a way you can disallow this property to be changed at lower level, but I am not aware of how to do that.
Reading MS Documentation of httpRuntime says that max limit is anyway set to 4MB by ASP.NET itself. I will try to find how to block lower level to modify this element in their web.config.
I have an ASP.NET web application where i am having multiple subrirectories in the root folder.in my root web.config, i have sessionMode as "StateServer" . So in one page of my subdirectory, i am not able to do serialization. If i change the SessionMode method to "InProc" , it will work fine. I want to maintain the web.config file in the root directory as it is.So i am planning about having another web.config file in sub directory.Can anyone tell me how to do this ?
Thanks in advance
While you can have a Web.config in every subdirectory not all settings are allowed at all levels.
And SessionMode is one setting that can only be made in the application-root.
You can just place a new web.config file in the sub-directory and ASP.NET will override any settings you change in that directory.
If you mark the class that is being put in the Session with the [Serializable] attribute, it can usually be used in an StateServer setup.
Just put another web.config in the subdirectory. ASP.NET allows for that, and I have several areas on my website where the web.config contains values specifically for that "application" specifically.
That said:
1) Are you sure it's a good idea to maintain state in two different ways? It would probably be better to figure out how to make your session state serializable or get rid of using session state altogether.
2) All those web.config files can get tough to maintain if you're not careful about what values you put in each.