I work on an ASP.NET web project which was migrated from target framework 3.5 to 4.5. After migration to 4.5 there is an issue with the redirecting of HTTP requests. A redirect from a called web page which is located in a subfolder causes a duplication of the root folder and subfolder in the called URL (but: no duplication with same code in 3.5). The affected subfolder is not registered as separate web application.
Hosted files are:
/WebAppRoot/SubfolderInWebApp/Page1.aspx
/WebAppRoot/SubfolderInWebApp/Page1.aspx.cs
/WebAppRoot/SubfolderInWebApp/Page2.aspx
/WebAppRoot/SubfolderInWebApp/Page2.aspx.cs
Page1 should redirect to Page2 using tilde (~) to address the root-relative path. Redirect call within /WebAppRoot/SubfolderInWebApp/Page2.aspx.cs is:
Response.Redirect("~/SubfolderInWebApp/Page2.aspx", false);
On my local machine using Microsoft Visual Studio and IIS Express the redirect points to
/SubfolderInWebApp/SubfolderInWebApp/Page2.aspx
On the test environment running IIS which hosts the app in WebAppRoot the redirect points to
/WebAppRoot/SubfolderInWebApp/WebAppRoot/SubfolderInWebApp/Page2.aspx
If I change the redirect call to
Response.Redirect("/Page2.aspx", false)
it works. But this is not really satisfying, knowing that it worked with the tilde before migration and keeping in mind that there are several other places in the application which work with the tilde (but not used in a redirect).
Here some details about my used setup:
local machine for development: Microsoft Visual Studio Professional 2017 15.9.49 (running IIS Express on local machine)
test environment: IIS 8.5.9600.16384
both setups use the
application pool ".NET v4.5 Classic" with .NET CLR version v4.0.30319 in classic pipeline mode
I wasn't able to identify possible reasons for this behaviour yet. As far as I understand the behaviour before the migration is the expected one. But I am not very experienced with ASP.NET, so maybe I misinterpret some information or I did not use the correct keywords in my search to find a solution. Also I did not identify issues in this list of breaking changes which could be the reason for the current behaviour. But maybe I am not aware of the impact of some statements in this list.
Any idea what might be wrong in my project? Is there an obvious configuration I miss? Is my expectation of the behaviour wrong? Thanks in advance for your help.
I solved it with help of Leo's answer here. The relevant control was firing an asynchronous postback which caused the described behaviour above.
When migration to 4.5 the HTTP module ScriptModule was removed from the web.config. Integrating this module again did not work for me and I wasn't aware of this. After defining the relevant control as PostBackTrigger by using the Triggers element within the UpdatePanel, it worked again:
<asp:UpdatePanel>
...
<Triggers>
<asp:PostBackTrigger ControlID="ControlWithSyncPostback" />
</Triggers>
</asp:UpdatePanel>
After this change everything works as expected again and there is no need to keep the ScriptModule declaration in the web.config (at least in my case).
I have two deploy pipelines in Azure DevOps that are deploying to IIS
a Website, That deploys to the server, has XML Substitution turned on and the connection and app strings are updated. This is Working fine.
a Web Application configured as a subfolder of the previous website. It Deploys to the server, has XML substitution turned on, however, Connection strings are not updated.
The log for the web application reports that XML Substitution has been applied successfully. But it has not actually been applied.
How can I Debug and solve this? Is this a known limitation to Web Applications? (which can inherit from the parent web.config)
I would provide more info, but I simply cannot find anymore.
Here is a solution that solve the similar issue,you can use as a reference.
In the contributor's case, he changed the following two to get it to work:
1.Configuration type - The template for IIS website deployment defaults the Configuration type to "IIS Website". He changed this to "IIS Web Application".
2.Package or Folder (probably the fix) - The IIS Web App Deploy task's Package or Folder option he had originally set to the artifact's drop folder's parent folder. That sentence was probably confusing - this value was $(System.DefaultWorkingDirectory)/_my-project-name-ASP.NET-CI. He changed this by browsing (the ... button) down to the actual /drop/my-project-name.zip file.
For details,you can refer to the cases mentioned in comment.
Can someone please confirm or deny my assumption below and/or offer any alternatives?
My Goal
I'd like to be able to precompile and merge my ASP.NET MVC 4 application (as documented here and here) when one-click publishing to our production environment.
The Symptom
I've got an ASP.NET MVC 4 project in Visual Studio 2012. My Web.config contains various entries that are removed in the Web.Release.config transformation. One of the removed entries is the entire configSections element because we maintain those entries in the production server's Machine.config.
However, when I configure my project to precompile and merge for release publication, I get the following error:
Unrecognized configuration section [our custom section name]
My Assumption
What I assume is happening is that it is precompiling everything locally before publishing to the production server (which makes perfect sense) but that part of that precompilation process is to resolve and validate the entire .config chain, from the project's Web.config up to my local Machine.config (which doesn't make much sense, practically). And since my local Machine.config does not declare configSections (or any of the other settings we rely on the production server's Machine.config for), the resolved Web.config doesn't validate.
And since the Web.config doesn't validate, the site can't be precompiled and so nothing is ever published to production.
The Rub
If that is indeed what's happening, then we won't be able to precompile, because the only solution I can think of (other than some potential configuration option I haven't been able to find) would be for all of our developers to have local copies of our production server's Machine.config on their machines. And that simply isn't reasonable because it defeats the whole purpose of having those common settings declared in a single location.
Documentation says if you have a context file here:
$CATALINA_HOME/conf/Catalina/localhost/myapp.xml
it will NOT be replaced by a context file here:
mywebapp.war/META-INF/context.xml
It is written here: http://tomcat.apache.org/tomcat-6.0-doc/config/context.html
Only if a context file does not exist for the application in the $CATALINA_BASE/conf/[enginename]/[hostname]/, in an individual file at /META-INF/context.xml inside the application files.
But everytime I re-deploy the war it replaces this myapp.xml with the /META-INF/context.xml!
Why does it do it and how can I avoid it?
Thanx
Undeploy part of redeploy deletes app and the associated context.xml.
If you use maven tomcat plugin you can avoid deleting context.xml if you deploy your app with command like this:
mvn tomcat:deploy-only -Dmaven.tomcat.update=true
More info here: https://tomcat.apache.org/maven-plugin-2.0-beta-1/tomcat7-maven-plugin/deploy-only-mojo.html
You can use deploy-only with parameter mode to deploy the context.xml too.
The short answer:
Just make the TOMCATHOME/conf/Catalina/localhost dir read-only, and keep reading for more details:
For quick deployment mode (Eclipse dynamic web project, direct Tomcat
connection, etc.) on a local/non-shared Tomcat server you can just define your JDBC datasource (or any
other 'web resource') using the META-INF/context.xml file inside the
WAR file. Easy and fast in your local environment, but not suitable for staging, QA, or
production.
For build deployment mode (usually for staging, QA, or prod), JDBC
datasources and other 'web resources' details are defined by the
QA/production team, not the development team anymore. Therefore, they
must be specified in the Tomcat server, not inside the WAR file
anymore. In this case, specify them in the file
TOMCATHOME/conf/Catalina/localhost/CONTEXT.xml (change Catalina
by the engine, and localhost by the host, and CONTEXT by your context accordingly). However,
Tomcat will delete this file on each deployment. To prevent this
deletion, just make this dir read-only; in Linux you can type:
chmod a-w TOMCATHOME/conf/Catalina/localhost
Voila! Your welcome.
The long answer
For historical reasons Tomcat allows you to define web resources (JDBC datasources, and others) in four
different places (read four different files) in a very specific order of precedence, if you happen to define the same resource multiple times. The ones named in the
short answer above are the more suitable nowadays for each purpose, though you could still
use the others (nah... you probably don't want to). I'm not going to
discuss the other ones here unless someone asks for it.
On tomcat7, also woth autoDeploy=false the file will be deleted on undeploy. This is documented and not a bug (althought it avoids good automated deployments with server-side fixed configuration).
I found a workaround which solved the problem for me:
create a META-INF/context.xml file in your webapp that contains
on the Server create a second context "/config-context" in server.xml and put all your server-side configuration parameters there
on the application use context.getContext("/config-context").getInitParameter(...) to access the configuration there.
This allows a per-host configuration that is independent of the deployed war.
It should also be possible to add per-context configurations by adding contexts like "/config-context-MYPATH". In your app you can use the context path oth the app to calculate the context path of the config app.
According to the documentation (http://tomcat.apache.org/tomcat-8.0-doc/config/automatic-deployment.html#Deleted_files) upon redeploy tomcat detects the deletion (undeploy) of your application. So it will start a cleanup process deleting the directory and xml also. This is independent of auto deployment - so it will happen upon redeployment through manager and modification of war also. There are 3 exceptions:
global resources are never deleted
external resources are never deleted
if the WAR or DIR has been modified then the XML file is only deleted
if copyXML is true and deployXML is true
I don't know why, but copyXML="false" deployXML="false" won't help.
Secondly: Making the directory read only just makes tomcat throwing an exception and won't start.
You can try merging your $CATALINA_BASE/conf/Catalina/localhost/myapp-1.xml, $CATALINA_BASE/conf/Catalina/localhost/myapp-2.xml, etc files into $CATALINA_BASE/conf/context.xml (that works only if you make sure your application won't deploy its own context configuration, like myapp-1.xml)
If someone could tell what is that "external resources" that would generally solve the problem.
The general issue as described by the title is covered by Re-deploy from war without deleting context which is still an open issue at this time.
There is an acknowledged distinction between re-deploy which does not delete the context, and deploy after un-deploy where the un-deploy deletes the context. The documentation was out of date, and the manager GUI still does not support re-deploy.
Redeployment means two parts: undeployment and deployment.
Undeployment removes the conf/Catalina/yourhost/yourapp.xml because the
<Host name="localhost" appBase="webapps" unpackWARs="true"
autoDeploy="true"> <!-- means autoUndeploy too!!! -->
</Host>
Change the autoDeploy="false" and Tomcat has no order anymore to remove the conf/Catalina/yourhost/yourapp.xml.
There is an feature that allowes us to make those steps (undeploy/deploy) as one single step (redeploy) that do not remove the context.xml. This feature is available via the manager-text-interface, but the option is not available using the manager-html-interface. You might have to wait until the bug in tomcat is fixed. You can use the method described in this answer as an workaround.
I'm using CassiniDevLib to host an MVC app for integration testing.
In order to do it I need to amend some config settings on the web server so they match the integration testing environment, first one being the connection string so it points to the test database.
I know I can have two copies of the web.config file and rename them but I was wondering if there was a more elegant way. ie a way to amend the settings in code as part of the Test Fixture setup. The challenge being that I need to access the web server process from my test ficture process
Would appreciate any thoughts on this.
I assume that you are using Visual Studio 2010. In that, you have a feature called as Config Transforms. Basically you can have multiple config file for each build environment. You can have your own custom build env. You have a new one by going to Configuration Manager and adding a new one.
http://blogs.msdn.com/b/webdevtools/archive/2009/05/04/web-deployment-web-config-transformation.aspx
you can search on the internet for Config Transforms, if you need more examples.