I have an ASP.NET project that was working correctly compiled with Visual Studio 2010 and NET4.0.
Then I have installed VS Express 2012 and NET4.5 and I always get an Exception trying to open a SqlConnection.
Can I have some chance to recompile my project targeting NET4.0 (so without disinstalling 4.5) and have it working?
In VS Express 2012 I have this web.config:
<system.web>
<compilation debug="true" targetFramework="4.0"/>
The referenced assemblies correctly target the v4.0, for example:
Assembly System.Data
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\System.Data.dll
EDIT 2
As this blog http://blogs.msdn.com/b/msbuild/archive/2007/04/12/new-reference-assemblies-location.aspx and also this answer https://stackoverflow.com/a/8543850/1012244 explains very well, there is a BIG difference betweeen Referenced Assemblies (folder contains those assemblies that ship with the x.xx Framework which are useful for referencing during the design and build of new components) and Runtime scenario (At runtime, these components will still be loaded from the GAC in most cases).
However, when I run the project I always get the Exception, as if the project actually was using NET4.5... Why?
PS. If I deploy this project on a production server machine with only NET4.0 installed, the connection is fine.
(This is clear now: Installing Net4.5 essentially replaces Net4.0)
UPDATED QUESTION -
Can I have some chance to recompile my project targeting an OLD NET4.0 .dll (System.Data.dll in my case) instead of the new Net4.5 dll?
EDIT - Additional info
At this MSDN link http://msdn.microsoft.com/en-us/library/ff602939.aspx I found:
If you determine that a change in the .NET Framework 4.5 has broken your application, check the Runtime Settings Schema to determine whether you can use a runtime setting in your application configuration file to restore the previous behavior.
Could this help me? And how?
I'm trying to up load my site and I'm getting this error message:
Unrecognized attribute 'targetFramework'. Note that attribute names are case-sensitive.
<compilation debug="true" targetFramework="4.0">
The site works fine on my local PC but won't open when I loaded it to my host and tried to view it online.
This typically happens when you have an attribute of targetFramework="4.0" in the web.config but the App Pool is set to run ASP.NET 2.0. The targetFramework attribute is entirely unrecognized by ASP.NET 2.0 - so changing it to 2.0 won't have the desired effect.
Contact Support / Your Administrator and have the AppPool switched to 4.0.
You could also remove the attribute entirely, however if your site was coded with the 4.0 Framework, then I'm sure something else will cause an error as well.
Registering the framework with IIS is what worked for me:
C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319>aspnet_regiis -i
In IIS
Click on Application Pools
Right Click on DefaultAppPool --->> Set Application Pool Default....--->>Change .Net Version to V 4.0.
open your IIS (type inetmgr in run) and change your Application pool setting,To view large this Image Right Click Image and open image in new tab
In Visual Studio menu:
Website -> Start Options -> build tab -> Select Target Framework in
Dropdown box (.NET FrameWork 4)
I was facing the same issue while publishing my 1'st web services. I resolved it by simply doing this:
Open IIS
Click on Application Pools
Right Click on DefaultAppPool => Set Application Pool Default => Change .Net Version to V 4.0. (You can also change
.Net Framework Version of your application specifically)
Hope, it'll work.
for IIS 7 try according to the given picture ... mark me helpful if it works for you.
I had to register ASP.Net in IIS to get it resolved in the Windows Server 2008 R2. Sreenshot of the commands attched below
cd /d C:\Windows\Microsoft.NET\Framework\v4.0.30319
iisreset /stop
aspnet_regiis -i
iisreset /start
%systemroot%\system32\inetsrv\appcmd set config /section:isapiCgiRestriction /[path='%windir%\Microsoft.NET\Framework\v4.0.30319\aspnet_isapi.dll'].allowed:True
%systemroot%\system32\inetsrv\appcmd set config /section:isapiCgiRestriction /[path='%windir%\Microsoft.NET\Framework64\v4.0.30319\aspnet_isapi.dll'].allowed:True
I'm using IIS Express, rather than IIS.
The problem was in the applicationhost.config file located in: {solution_folder}\.vs\config\applicationhost.config.
One of the application pool entries had a managedRuntimeVersion value of "v2.0". I changed it to "v4.0", and it worked properly.
I'm fairly sure the root cause was one of the NuGet packages I had installed recently.
<system.applicationHost>
<applicationPools>
<add name="BadAppPool1" managedRuntimeVersion="v2.0" managedPipelineMode="Integrated" CLRConfigFile="%IIS_USER_HOME%\config\aspnet.config" autoStart="true" />
</applicationPools>
</system.applicationHost>
Change the application pool to target framework 4.0 instead of classic .
RC website ->manage website->advanced setting>
the first option change from classic to framework 4 integrated.
Open Project -> press Shift + F4 (Open properties page) -> Chose Build -> in Target Framework chose .NET Framework 4 -> OK
I also got the same issue while running my application locally which is pointing to .Net Framework 4.7.1.
The bug was "Unrecognized attribute TargetFrameWork" as shown below.
But none of the above answers helped me. At last when I changed my present port (1413) number to some other value(60179) as shown below it worked fine for me.But I am not sure for the actual reason behind this , but it worked.
Create a new pool by selecting .Net Framework v4.0.3xxxxx
use the Manage Pipeline Mode: Integrated
Assign it to your site and done.
To fix this problem simply click the ASP.NET Version icon in the Site Tools section of Control Panel to switch the framework to 4.0.
I had this error from a failed MSBuild compile, in a project file converted from an earlier version of VS into VS2010 and .NET 4.0. It was actually a Web Deployment project, and the solution that worked for me was adding the following entries into the PropertyGroup section at the start of the MSBuild file:
<ProductVersion>10.0.11107</ProductVersion>
<TargetFrameworkVersion>v4.0</TargetFrameworkVersion>
Maybe these get automatically updated when other types of project are converted in VS2010, but they were missing from my Web Deployment project file after it was converted.
What I did:
I did change the value of Application Pool to DefaultAppPool from a previous value. You do this in the Advanced Settings (Website --> Manage Website --> Advanced Setting>.
Just had this in VS 2010.
Fixed by editing the .sln file and changing the TargetFrameworkMoniker to have the value ".NETFramework,Version%3Dv4.0" assigned to it.
If you're using IIS Express, it creates a new configuration for each site that you run, and it's bound to the url (host/port). However, when it opens a new project using the same port it doesn't refresh the configuration.
This means that if you have a project using CLR 2.0 (.NET Framework 2.0 to 3.5) running on some port and then later you open another project in the same port using CLR 4 (.NET Framework 4.x+) the new project will try to run using CLR 2, which fails - and in case it doesn't even recognize the "targetFramework" attribute.
One solution is cleaning IIS Express sites, but the easiest method is changing the port so that IIS Express will create a new site (using CLR 4) for your project.
If you compile the files and the value of the "targetFramework" is set as being a particular version i.e. 4.0,
Make sure the host is running .net framework as the same version stated.
If not, download the .net framework.
After downloading, if it is not automatic being set in the IIS manager to be using the extension of the newly downloaded version of .net framework,
add the extension manually by going to the folder of the recently downloaded .net framework THROUGH IIS manager:
1.right-click website folder
2.go to "Properties"
3.under "virtual directory" , click "configuration"
4.edit the executable path of extension ".aspx" (of which the path being pointed to version other than the version of the recently downloaded .net framework) to the correct path which is the folder of the NEWLY downloaded version of .net framework and then select the "aspnet_isapi.dll" file.
5.click ok!
Just Remove the "Target Framework 4.0" and close the bracket.
It will Work
Follow these two steps:
Register the .net framework version version 4.0 (if it is not registered)
C:\WINDOWS\Microsoft.NET\Framework\v4.0.30319>aspnet_regiis -i
In the app pool change the .net framework to v4.0
If you install the IIS after the installation of .Net FrameWork. You need install the .net framework again for IIS. So all we need to do is run aspnet_regiis -i. Hope it is helpful.
Saw the error "Unrecognized attribute 'targetFramework'" in the 'Console output' page of Jenkins on a build server.
This was after I changed the 'target framework' for several projects from '.NET Framework 3.5' to '.NET Framework 4' and committed my changes.
In Jenkins the project settings had to be changed. For the solution the 'MSBuild Version' had to be changed from 'v3.5' to 'v4.0'.
Just had this issue deploying a new app to an old IIS box. The investigation led to the v4.5.1 run-time being installed but the app requiring v4.5.2
Nothing apart from installing the correct version of ASP .Net run-time was required.
It could be that you have your own MSBUILD proj file and are using the <AspNetCompiler> task. In which case you should add the ToolPath for .NET4.
<AspNetCompiler
VirtualPath="/MyFacade"
PhysicalPath="$(MSBuildProjectDirectory)\MyFacade\"
TargetPath="$(MSBuildProjectDirectory)\Release\MyFacade"
Updateable="true"
Force="true"
Debug="false"
Clean="true"
ToolPath="C:\Windows\Microsoft.NET\Framework\v4.0.30319\">
</AspNetCompiler>
For layering,
Just change the version of targetFramework in web.config file only, the other things no need change.
I had the same issue and I found this nice poweshell script to update all of your app pools at the same time:
https://gallery.technet.microsoft.com/scriptcenter/How-to-set-the-IIS-9c295a20
Make sure to set you $IISAppPoolDotNetVersion = "v4.0" variable at the top.
following 2 steps will force refresh Visual Studio and IIS Express cache and usually resolve my similar issues:
Simply switch Project framework from 4+ to .Net framework 3.5 and run it
If it ran successfully you can revert it back to your desired 4+ target framework and see that it will probably work again.
Changing the port number for the local development helped me Thanks #Rinay Ashokan.
I have done all the trouble shooting and finally found that the project configurations are stored in the IIS express for the port number.
For anyone having this who doesn't have IIS running on their dev PC, here's what happened to me: I had one website on, overwrote with files from a diff website that was 4 while the previous was 3.5. Got this error. Fixed it simply by changing the directory name of the website, which on a dev PC can be anything, so no problem.
The above are probably more elegant to be sure, but sometimes simple works, IF you can get away with it, i.e., you're in dev rather than QA or Prod.
I'm trying to set up a web app (32bit on ii7/win7, 32bit setting is enabled, everything is compiled to x86, using vs2008), but there's clearly some dll module loading issue happening. I've been watching procmon and fusion logs but I'm not seeing the name of the missing dll.
I'm a complete newbie to asp.net (but fairly heavy experience on other platforms).
I know I can call depends.exe on a binary to see what the dependancies are, but how do I do it for asp.net? specifically, is it possible to get a list of the dlls that iis7 loads for my application?
update: I manually blew away all of the binaries for my application and rebuilt (clean didnt seem to do the trick, I guess). it's now sort of working. or at least it's getting further and more detailed.
An asp.net web project dll shouldn't depend on anything that is not part of the default .net run-time or explicitly referenced in the project. I would start by reviewing the references. Noramlly an asp.net web project has a bin folder that contains the compiled website/webapplication and any dll's that it depends on (aside from the .net run-time). This is usually done by the programming tool used to create the project.
If you still don't find the culprit, you could try using Filemon (http://technet.microsoft.com/en-gb/sysinternals/bb896642.aspx) and use it to watch IIS to see what files it is looking for and isn't finding.
An additional option is to examine the web.config file that should have been included with the web site/application. Its an XML file and usually has an Assemblies section that lists assemblies that should be loaded. For example you might see:
<assemblies>
<add assembly="MySql.Data, Version=6.2.3.0, Culture=neutral,
PublicKeyToken=C5687FC88969C44D"/>
</assemblies>
This means that the code wants to use the MySQL.Data.dll, and specifically version 6.2.3.0 of that DLL. It is possible to have different versions of .Net dll files installed at the same time. So you might have the desired DLL, but not the correct version as specified in the Web.Config file.
I had an ASP.NET 2.0 web project. Worked fine. I decided to upgrade the site to 3.5. The upgrade worked fine. I have added a IHttpHandler that required to include the following line in the web.config:
<add verb="GET,POST" path="MyOperation.asmx" type="MyClass"/>
This line in the web.config generates the following error: "Parser Error Message: Could not load type 'MyClass'."
This sounds like a typical spelling error in the class name. But it looks not, I checked it 1000 times. However, what is really strange that on the bottom of the "yellow-screen-of-death" page it says:
Version Information: Microsoft .NET Framework Version:2.0.50727.3082; ASP.NET Version:2.0.50727.3082
This is really strange. The project is set to 3.5. The only piece of code that use 3.5 features are the IHttpHandler implementation. All the rest of the web project are 2.0 compatible and works without problem if I exclude the line from the web.config.
Why is this?
[I did not try with IIS. I use ASP.NET development server.]
[EDIT] I have to apologize, it was stupid spelling issue as I expected in the first round. My IHttpHandler implementation was in a nested class and the proper class name is "OuterClass+NestedClass" vs OuterClass.NestedClass that I used in my config file. However, I thank to all who contributed because I learned new things on CLR versioning!
I think you need to use the fully qualified type name.
Like:
<add verb="GET,POST" path="MyOperation.asmx" type="Your.Namespace.MyClass, assembly.name"/>
and the error containing the version information of 2 is normall since the CLR hasn't changed for 3 and 3.5. the only changes were additional sepperate assemblies and syntactic suggar (like automated properties are a feature of the compiler not the runtime) ".net 4" will come with a new CLR.
The version is not an issue ( I think). .net 2 to 3.5 sp1 use the same run time. The newer ones are just new libraries and compilers. So from the asp.net point of view not much has changed.
ASP.NET 3.5 is really 2.0 with extra extensions. So, as long as the server has 3.5 installed, then the message that shows that you're pointing to the 2.0 framework confirms that you have it setup correctly.
The issue is likely what olle suggested, that you need the full class name, assembly name.
Also confirm that you have the dll in your /bin folder and that it's marked as an application if you're not working from the root of your site.
Go to the project properties. Choose the Application tab. Change the Target Framework to .Net Framework 3.5 if you haven't done that already.
I am a developer and am trying to create a very basic "Hello World" .NET 3.5 web app. However, whenever I publish the code I am getting the following error.
Parser Error
Description: An error occurred during the parsing of a resource required to service this request. Please review the following specific parse error details and modify your source file appropriately.
Parser Error Message: Could not load the assembly 'App_Web_default.aspx.cdcab7d2'. Make sure that it is compiled before accessing the page.
Source Error:
Line 1: <%# page language="C#" autoeventwireup="true" inherits="_Default, App_Web_default.aspx.cdcab7d2" %>
Line 2:
Line 3: <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
Here are the steps I'm taking.
Open VS2008 and create a new website using C# and .NET Framework 3.5.
Update Default.aspx to say "Hello World"
Make the following changes to web.config
** add <customErrors mode="Off"/>
** comment out <authentication mode="Windows" />
Publish the site, checking the boxes for "Allow this precompiled site to be updateable" and "Use fixed naming and single page assemblies"
What I would like to know is if this is something I am doing wrong or something our web admins have setup incorrectly.
Would/could it have anything to do with where the /bin directory is located?
If you do not have access rights to the deployment server, best way to learn the framework version which your application running is to look at the bottom of the common ASP.NET error page. You can find the Framework version like that :
Version Information: Microsoft .NET
Framework Version:2.0.50727.3053;
ASP.NET Version:2.0.50727.3053
Here is a post from MSDN:
http://msdn.microsoft.com/en-us/kb/kb00318785.aspx
Are you using the correct .NET-version in IIS ?
The version in the combobox must be correct:
(screenshot only showing .NET 1.1 & 2.0)
alt text http://helpdesk.nucleus.be/content/installatie-van-dot-net-3-5/iis_dot_net_3_5.jpg
I would start by publishing the site without pre-compilation first. If it still does not work, then work with your web admin to check the following:
You can see which versions of .net are installed by looking in:
C:\Windows\Microsoft.NET\Framework
You should have a folder for every version of the framework installed, for example:
v1.0.3705
v1.1.4322
v2.0.50727
v3.0
v3.5
If IIS was installed after .net 2.0, you may need to run aspnet_regiis to install or repair the .net IIS installation:
C:\Windows\Microsoft.NET\Framework\v2.0.50727\aspnet_regiis -i
Please note that in IIS you will only see v1.1.4322 and v2.0.50727 in the framework dropdown (.net v3 and v3.5 use the v2.0 runtime). Your site will need v2.0.50727 selected.
You will also want to make sure that the account your web app is running under (usually Network Service on servers) has the correct permissions on the folder that contains your web app files (read should be sufficient for your test).
The problem actually was that our web admins set up the site at a higher directory then what I thought. Therefore, when I published the site, the bin folder was not at the root of the site. That is why the files could not be found.