IIS7 to IIS6 migration web.config problems - asp.net

I have a web application that I wrote in Visual Studio 2008 that targets .Net Framework 3.5. To test it I used a machine running Windows 7, which means IIS7. My application works just fine on this but when it was deployed to a development server (running server 2003, so IIS6) it doesn't work.
The first few lines of my web.config file are as follows:
<?xml version="1.0"?><configuration>
<configSections>
<sectionGroup name="system.web.extensions" type="System.Web.Configuration.SystemWebExtensionsSectionGroup, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35">
<sectionGroup name="scripting" type="System.Web.Configuration.ScriptingSectionGroup, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35">
The error I get has to do with the type= part of the sectionGroup tag. I don't remember the exact message, but it is something along the lines of 'invalid tag' or 'invalid attribute.'
I have two questions:
First, is anyone savvy enough with IIS to know why this works in 7 and not 6?
Second, why do I need the sectionGroup tag? What does it do?
I checked the dev server to make sure the right version of .net was installed. It has 2, 3, 3.5, and 4, so I should be covered on that front.
I'm rather new to .net (probably obvious by now), so please forgive me if this has been asked a thousand times and it looks like I'm beating dead horses. My googling and searching of stackoverflow didn't provide a solution.
SOLUTION:
The whole problem was IIS not being configured correctly. The asp.net tab of the website's properties was set to 2.0.something. We changed it to 4.0.something (3.5 wasn't an option) and everything works just fine.

Your framework targets .NET 3.5. It probably doesn't matter whether you use the scripting section or not, but the scripting section is configured with 3.5. This is used for the client scripts of the ASP.NET Ajax Scripts.
If you run your application in IIS 6, it depends on which framework version you have configured for the application pool. If you mix your applications, it might start in the wrong version. Check that you configure your pool correctly. Unfortunately I don't have an IIS 6 here I can't remember exactly how you do that. Important is that you have no other application in another .NET version running in the same pool.

Related

Why does my web application automatically gets the nuget package Microsoft.CodeDom.Providers.DotNetCompilerPlatform added to it?

When I create a new web application (.net 4.6.1) using Visual Studio 2017, I get a nuget package installed (Microsoft.CodeDom.Providers.DotNetCompilerPlatform) and my web.config file contains the following:
<system.codedom>
<compilers>
<compiler extension=".cs" language="c#;cs;csharp" warningLevel="4" compilerOptions="/langversion:7.0 /nowarn:1659;1699;1701;612;618" type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.CSharpCodeProvider, Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=3.6.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
<compiler extension=".vb" language="vb;vbs;visualbasic;vbscript" warningLevel="4" compilerOptions="/langversion:default /nowarn:41008,40000,40008 /define:_MYTYPE=\"Web\" /optionInfer+" type="Microsoft.CodeDom.Providers.DotNetCompilerPlatform.VBCodeProvider, Microsoft.CodeDom.Providers.DotNetCompilerPlatform, Version=3.6.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
</compilers>
</system.codedom>
What is the use of this codedom here?
From what I gather so far this is related to the new rosyln compiler.. but I don't see why this is needed here.
If I remove this NuGet package, it removes these lines from the web.config file as well.. But nothing seems to be affected as far as my web application is concerned.
I thought if I check the runtime directory, it might point to the bin\roslyn, folder.. but it doesn't it still point to: C:\Windows\Microsoft.NET\Framework\v4.0.30319\
So, I am wondering what is the use of this package? and why is this added to my web app by default?
Hard to tell. It also will depend if you using a asp.net application vs that of a asp.net web site.
For example, while a web site applcation does a FULL compile and creates all the .dlls BEFORE publish to the web site? That means the web site DOES NOT re-compile your code.
However, I been bitten, since app_code DOES get re-compiled. I introduced some vb.net code, and started using the free text ability. (really nice for in-line sql statements).
However, when app_code attempted to re-compile that code (IIS + asp.net web site does), then that code would not compile anymore.
My simple solution? I simple create a new folder called MyCode, and set the properties of each code modules (my global utility routines) to compile.
eg this:
In other words, I 100% dumped the use of app_code, since while ALL other code is pre-compiled (I'm using a asp.net web site applcation and NOT a asp.net web site).
So, while in most cases you don't care or need Roslyn support, and everything "seems" to work on your local computer during development? Be careful, if you introduce code syntax that depends on some of the Roslyn features, then at deploy time, when the web site attempts to compile the code, it will not have Roslyn.
(its possible that the web server can be updated to support Roslyn, but I don't really know, and I don't want to find out!).
And since you seem to have both c# and vb.net setup? Then this suggests you may well be running a mixed environment, and thus NOT using a web site applcation, but using a web site, and THAT means that IIS and the web site going to do the compiling here, not your local dev machine before deploy.
This then does mean some caution is required, and I would probably suggest you disable use of Roslyn during development.
So, I can't be 100% sure - but it the simple answer is they shoved in a nuget package to help with this issue.

ASP DevExpress libraries undefined after server migration

I'm having trouble migrating the DevExpress elements of an ASP web application from one server to another. I basically copied the files and database over into a new server location and made some adjustments to the web.config file to get it connected to the new database. That got most of the site working and pulling data correctly, but the DevExpress pieces are coming up as undefined.
As far as I can tell, the references in the web.config file and on the respective pages is correct and the dll files themselves are listed in the bin directory so I'm rather stumped as to why they aren't working.
Web.config sample
<compilation debug="true" strict="false" explicit="true">
<assemblies>
...
<add assembly="DevExpress.Web.ASPxGridView.v10.1, Version=10.1.6.0, Culture=neutral, PublicKeyToken=B88D1754D700E49A" />
<add assembly="DevExpress.Web.v10.1, Version=10.1.6.0, Culture=neutral, PublicKeyToken=B88D1754D700E49A" />
... and so on
Dashboard.aspx sample
...at top of page...
<%# Register Assembly="DevExpress.Web.ASPxGridView.v10.1, Version=10.1.6.0, Culture=neutral, PublicKeyToken=b88d1754d700e49a" namespace="DevExpress.Web.ASPxGridView" tagprefix="dx" %>
This was an inherited project, so I haven't tried rebuilding the application in case my machine imports my settings into the project (example: it was made in VS 2008, and I'm running VS Community 2015).
Are there any quirks to making a transfer like this that I just don't know about or has anyone else experienced this issue? Any help would be appreciated.
Thanks
The first thing that comes to mind is that version 10.1 of DevExpress is a very old version, released in Aug '10. It does not support .Net 4, so you'll need to make sure the application pool for IIS running this web app is .NET CLR Version 2.0.
Note that if you are running in Windows Server 2012, it's actually tricky to install .Net 3.5. Google how to do it if you need to.
The next to check of course if all of the dll's referenced are in the Bin folder.
Could you write the error message you are getting? If it does not have any extra information, perhaps the event viewer of the server (under windows logs/applications) has a more detailed description.

Changing visual studio compiler version

Visual Studio is compiling Asp.Net to 4.0, but I need it to compile to 3.5. Where do I change this?
According to this (right click project, property pages, build) it is targeting 3.5, but I'm fairly certain based on the errors I'm getting with install that it's requiring 4.0 components.
Have you checked the <compilation> section of the Web.config file? If it still reads targetFramework="4.0" try removing/changing this value. This has worked for me in the past.
Don't forget, it doesn't matter what you version you compile too, if the web server is configured to run your app under a particular version, it will do. Some ways will work, ie compiled to 3.5 will work in 4.0 app pool. other way round won't.
On IIS7 the version is defined in the app pool associated with your app. IIS6 it's in the ASP.Net tab.
manually in the web.config file
And Automatically in visual studio, in the solution explorer, right click (in the web icon not in the solution icon) -> property pages -> build -> target framework -> change value.
You can check it, viewing the web.config.
name="system.web.extensions"
type="System.Web.Configuration.SystemWebExtensionsSectionGroup,
System.Web.Extensions, Version=3.5.0.0, Culture=neutral,
it indicate that the web is using net framework 3.5

System.ServiceModel.Activation.HttpModule error

what is the cause of this error on below line?
<system.web>
<globalization fileEncoding="utf-8" requestEncoding="utf-8" responseEncoding="utf-8" culture="fa-IR" uiCulture="fa-IR" />
<compilation targetFramework="4.0" debug="true">
<assemblies> <add assembly="System.Data.Entity, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" />
Everywhere the problem to this solution was mentioned as re-registering aspNet by using aspnet_regiis.exe. But this did not work for me.
Though this is a valid solution (as explained beautifully here)
but it did not work with Windows 8.
For Windows 8 you need to Windows features and enable everything under ".Net Framework 3.5" and ".Net Framework 4.5 Advanced Services".
Thanks
Neha
This happens when you install .Net 4 before enabling IIS, or if you register WCF after registering .Net 4. In either case, your App Pools will be running .Net 2.0 (which is the CLR version required for .Net 3 if you have registered WCF, which installs ASP.Net 3.5, or the default if you have installed IIS after .Net 4)).
There are many references to this on the web, e.g. the MSDN blogs:
http://blogs.msdn.com/b/webtopics/archive/2010/04/28/system-typeloadexception-for-system-servicemodel-activation-httpmodule-in-asp-net-4.aspx
The fix is to re-register ASP.Net 4 from the correct (32 or 64 bit) Framework folder (Framework64 on a 64bit server), using the aspnet_regiis.exe tool, e.g.
aspnet_regiis.exe -iru
For Windows 8 you need to Windows features and enable everything under .Net Framework 3.5 and .Net Framework 4.5 Advanced Services -> Enable Everything
For windows 8 the above configuration in
Control panel->programs->windows features on/off
enable every thing under".net Framework3.5" and ".net Framework 4.5 advanced Services"
Working fine for me.
Thanks Madhavi.B
I had this problem on a server managed by one of our clients. I didn't have the access to run the aspnet_regiis.exe tool. As a workaround I did the following:
I removed aspNetCompatibilityEnabled="true" from the <serviceHostingEnvironment> tag in the web.config
removed [AspNetCompatibilityRequirements] from the webservice.cs file
Unfortunately this means that for example HttpContext.Current becomes null, I could fix my webservice by rewriting all my HttpContext.Current.Server.MapPath calls to System.Web.Hosting.HostingEnvironment.MapPath
Hope this helps someone.
This problem surfaced for us immediately after we installed the Windows Management Framework 3.0/PowerShell 3.0 sp1 (KB2506143) on a Windows Server 2008 R2 x64. Windows Update then also installed KB2736422, KB2756921, and KB2656411 immediately after.
Our solution was to first uninstall KB2506143 (and the three updates that accompanied that), then run aspnet_regiis.exe -iru as suggested in Ed209's response above. Both steps were necessary to resolve the problem. Thank you, Ed209.
appcmd.exe set config -section:system.webServer/modules /[name='ServiceModel'].preCondition:"managedHandler,runtimeVersionv2.0" /commit:apphost
worked for me

Trouble deploying code written on VS2008 to server running .NET Framework 2.0

When I created the project I'm trying to deploy I selected that I wanted to target .NET Framework 2.0. After deploying the project I try to brows to it and get and error page that shows:
<compilation debug="true">
<assemblies>
<add assembly="System.Web.Entity, Version=3.5.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>
<add assembly="System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31BF3856AD364E35"/>
<add assembly="System.Core, Version=3.5.0.0, Culture=neutral, PublicKeyToken=B77A5C561934E089"/>
</assemblies>
</compilation>
One of the selling points of VS2008 is that you can develop for and deploy to server running .NET2.0 what Am I doing wrong?
Right click on your project and select "Properties." From there, select the "Compile" tab and click the "Advanced Compile Options" button down at the bottom left. The last drop down list item should be "Target Framework" and you can select 2.0 from there. As mentioned above, this is provided you're not using any 3.5 related technologies such as LINQ.
Save, recompile and deploy. Once everything is set, you can go back and select the 3.5 option to target the 3.5 framework again.
Hope this helps!
Oh, one other thing to note. If you are using the AJAX Toolkit controls in your 3.5 application (calendar extender, auto-complete extender, etc.), you'll need to make sure you download the 1.0 Toolkit from the codeplex site since the 3.5 toolkit is not compatible with the 2.0 framework.
You are referencing assemblies of the .NET Framework 3.5, are you using EntityDataSources??
Remove those 3.5 references...
You also need the AJAX Extensions (System.Web.Extensions) for .NET 2.0 on the server.
remove those references from your project and redeploy. if your project started as 3.5 it will still have references to some of those assemblies
If you're using features from the 3.5 framework, then you'll have to deploy to a 3.5 machine.
Most information you'd probably need for this issue is in the question and answers here:
problems-executing-compiled-35-code-on-a-server-which-only-has-the-20-framework

Resources