I have a web application that usually runs with a .NET 2.0 AppPool account. But because the AJAX calls posts string serialized XML to the server, I needed to add the "requestValidationMode" option to the httpRuntime setting when running the same AppPool account with .NET 4.0.
However, switching back to .NET 2.0, the application responds with error with regards to the "requestValidationMode" option.
Is there a way one can have one web.config with some conditional mark-up so one need not edit the web.config each time the version of .NET is changed for the AppPool?
Any help would be greatly appreciated.
Related
We have a legacy web api project developed years ago, it is supposed to be consumed by other internal projects (so not something to be exposed by users over Internet).
The prject was developed in .net 4.6.1 and I am looking at moving it to .net 6. By reading the code and web.config, I got confused with these:
Is it acceptable or best practice to keep on using web.config in .net 6 for these settings or it is better to do in other places? (seems I can't type web.config in stackoverflow and have to make a screenshot)
In our web.config, we have this: <httpCookies httpOnlyCookies="true" requireSSL="true" />
For this web api, we just send some response back and I can't think a place that we use cookie. For authentication, as this web api is consumed by other internal products, we just authenticate the bear token each request sent with the identity server. So is this line really needed? I can't find an equivalent line in .net 6's web.config
There are different ways on specifying application settings in .NET 6, depending on what kind of setting it is and how you want to structure your project. As Marc says the most common application configuration file for .NET Core is that I have seen is: appSettings.json.
You might want to configure some settings directly in your Program.cs and other settings (especially settings that need to be transformed between environments) could be in a transformable settings file like appSettings.json or lauchSettings.json. Read more about configuration in .NET 6 here.
To conclude I would say that it is not best practice to keep the web.config but rather to extract the configuration to the place you see fit. If you don't host you app on a server that needs web.config to run then remove it.
This is a bit harder to answer. If you don't think you need this setting then you can try to omit it when you migrate your application to .NET 6. If you have multiple environments you should test your application (the .NET 6 version) in a non production environment and then you will get your answer if you need to configure that setting or not in the migrated application.
I wish you good luck in your migration journey! :)
I have upgraded my asp.net application from framework 2.0 to 4.0 and with this stated I am also running one web service which is in framework 2.0.
On deploying to the server, I am not able to get the output of the web service while application is running alright
Do I need to upgrade the version of web service too?
And any change in app.config file required?
The easiest way forward is going to be to upgrade the web service to v4.x as well. Each application pool can only be tied to a single version of the .Net framework. It is technically possible to host a 2.x application inside of a 4.x site, but it will save a lot of trouble in the long term to standardize on a single version of the framework.
As This article describes:
If an IIS Web application that targets the .NET Framework 3.5 or
earlier is nested inside an IIS Web application that targets the .NET
Framework 4, the compiler might report errors when it compiles the
nested application. This is because Web.config files inherit settings
from files that are higher in the configuration file hierarchy.
If you don't want to upgrade the service, your best bet is to prevent web.config inheritance. This blog post has details on a few different ways to accomplish this.
We have two server running .NET 4.5.1 and one running .NET 4.0. Before updating the first two, our SSO for forms authentication worked fine. Now, a user will appear authenticated on those first two servers, but not authenticated on the .NET 4.0 box.
All machine keys, decryption keys, cookie domains, etc, are all the same. No code was modified. We simply applied the 4.5.1 update to those two servers.
I've noticed for the 4.0 server, while our authentication cookie IS being passed up, it's not being recognized by the code (I threw a test page on the site and outputted some variables).
Has machine key encryption changed between 4.0 and 4.5.1? Do I need to apply some patch? Thanks.
The encryption APIs have changed in 4.5 see this blog post for more detail - http://blogs.msdn.com/b/webdev/archive/2012/10/23/cryptographic-improvements-in-asp-net-4-5-pt-2.aspx
According to MS simply upgrading to 4.5 wouldn't affect the apps unless the web.configs have changed to target 4.5 which seems odd in your case. You can try adding this attribute to each web.config to force .NET 2.0 compatibility-
<machineKey compatibilityMode="Framework20SP1" />
I have just upgraded my ASP.NET application from .NET 3.5 to 4.0 and have found that the Request.RawURL is set to "/" when requesting the default document, default.aspx, via http://mysite.com/. In .NET 3.5, the Request.RawURL would be set to "/default.aspx".
Is there any way to enable this .NET 3.5 behavior in 4.0?
I have tried disabling extensionless URLs via the registry. I also went through the ASP.NET 4.0 Breaking Changes doc and have set the form tag action attribute, however viewing the source of the page shows that the value set for the action attribute is not being picked up and is reverting back to "/".
Currently running on IIS 7.5 integrated mode and Win7.
Indeed, I can reproduce the behavior when switching between .NET 2.0 and .NET 4.0 -- .NET 2.0 & 3.5 both share the same Common Language Runtime CLR2, with additions to the base class library (BCL) for the higher versions of .NET. With .NET 4.0 came CLR4 and that seems to be where the difference occurs. I never noticed that before!
I believe the new behavior is correct, as RawUrl reflects the URL path that was actually requested. It's difficult to understand your exact need, but I think you might try using Request.Path instead.
URL: http://example.com/
Request.RawUrl: /
Request.Path: /default.aspx
Perhaps you can elaborate a bit more on your application?
I've currently got a ASP.NET MVC 2 application on .NET 3.5 and I want to migrate it over to the new .NET 4.0 with Visual Studio 2010.
Reason being that it's always good to stay on top of these things - plus I really like the new automatic encoding with <%: %> and clean web.config :-)
So, does anyone have any experience they could share? Looking for gotchas and the likes.
I guess this could also apply to any ASP.NET Forms projects aswell.
TIA,
Charles
Gotcha #1 - Changes application pool
If your ASP.NET project is setup to use IIS and not Cassini, during the upgrade to .NET 4.0 process it'll automatically change the application pool that your site uses to the new ASP.NET v4.0 application pool. This may have an effect on permissions if you are using the application pool identity for anonymous authentication.
Gotcha #2 - [ValidateInput(false)] stops working
This is a breaking change in ASP.NET 4.0. A related question can be found here.
The jist is that you must add <httpRuntime requestValidationMode="2.0" /> into your web.config.
I just went through that process. It was relatively painless. It'll give you a chance to do some house cleaning with your web.config files, as you mentioned.
There's one area I had trouble with. If you're taking advantage of the post build ASP.NET compile task in the project file via MvcBuildViews = true, you may experience a problem if you then attempt a publish. Apparently VS 2010 stages files within your project's subdirectory, resulting in the ASP.NET compiler detecting multiple web.config files. There's a full explanation and a response by Microsoft on this post:
http://forums.asp.net/p/1547458/3797505.aspx
Otherwise the process was pretty smooth.