I have moved a couple of DLL files in the BIN folder but Visual Studio is not picking these up. Do I need to manually register them for 1.1?
I know in later frameworks, it is as easy as moving DLL files in the BIN folder but the same is not working for framework 1.1. Is there anything I am missing?
You should reference the DLL in the project.
More info below;
http://msdn.microsoft.com/en-us/library/wkze6zky(v=vs.71).aspx
Running the MSI file and Restarting Visual Studio 2003 resolved the problem. ASPOSE.CELLS.DLL is 1.1 compatible so backward compatibility was not the issue.
You just need to declare your assemblies to your web.config just like the following:
<configuration>
<system.web>
<compilation>
<assemblies>
<add assembly="MyDll"/>
</assemblies>
</compilation>
</system.web>
</configuration>
You'll have also to make sure that your dll are compiled for .NET 1.1. Or else, it won't work.
Hope this helps you. Let us know if it is still not working.
Related
I'm working on a large ASP.NET solution. Inside the solution are multiple ASP.NET projects. Inside each project, is a web.config file. A few weeks ago, I tried to upgrade all of the projects from .NET 4.5 to .NET 4.7. I did this by right clicking each project in solution explorer, going to properties, and setting the .NET version on the screen that pops up. Using this method, I was able to easily change all of the projects in the solution to 4.7 (or so I thought). A few days later, I looked at the web.config file for one of the projects and saw this (incomplete file):
<system.web>
<httpModules/>
<httpRuntime enableVersionHeader="false" targetFramework="4.5"/>
<sessionState REMOVED>
<providers>REMOVED
</providers>
</sessionState>
<compilation debug="true" targetFramework="4.7">
From what I can tell, the project I'm running uses 4.7, and ignores the 4.5 targetFramework code. I can access 4.7 API calls, and rolling the code back to 4.5 using the method shown above disables the 4.7 API calls. Still, I can't help but worry.
To make things more complex, I have text like this in my packages.config file:
<package id="EntityFramework" version="6.1.3" targetFramework="net45" />
With all that being said, is my project running in 4.7, 4.5, or some kind of bizarre mix?
Is my code safe, or is it going to self destruct in some kind of bizarre edge case?
Probably a noob question but what version of .NET is used in a ASPX web application? Is it the version defined in the project propperties or the one defined in the web.config file of the website?
I need to know this because an API I am using in the web application is closing all non TLS1.2 protocolls. And as far as I understand TLS1.2 is the default in .NET 4.5. The server is Windows Server 2008.
Visual Studio uses web.config values to initialize the property pages. So, they're one in the same.
You see the .NET version from the property pages in the web.config similar to this:
<configuration>
<system.web>
<compilation targetFramework="4.5" />
</system.web>
</configuration>
If you change the target framework in the project properties and save, you should see the updated target framework in that value in your web.config file.
One of our ASP.NET MVC 5 web applications has the following web.config settings:
<system.web>
<compilation debug="true" targetFramework="4.6" />
<httpRuntime targetFramework="4.5" />
<!--... many other things -->
</system.web>
It is not clear why are two targetFramework settings, and it seems to be wrong to compile targeting 4.6 then trying to run under 4.5...
Obviously I am missing something, but what?
The reason of targetFramework existence in web.config is to keep compatibility issues out between breaking changes for each version of .NET Framework. The difference between targetFramework on compilation and httpRuntime belongs to each development and deployment environment.
According to MSDN blog:
<compilation targetFramework="4.6" />
Selects which version of the .NET Frameworkâs reference assemblies are
used when performing compilation. (Note: Visual Studio requires that
this element be present in Web.config, even though we auto-infer it.)
This element determines the assembly version used during compilation to create dependencies and related assemblies from current project.
<httpRuntime targetFramework="4.5" /> means that current project designed to use .NET 4.5 runtime assemblies without recompiling existing project assemblies in deployment machine before loading it into memory.
Hence, we can conclude that version number defined on targetFramework in httpRuntime element designed to maintain compatibility between compiled project and available assemblies in runtime usage, depending on which version of runtime files being used in target machine.
Thus, in your case, this is not a wrong behavior, the project creator(s) simply want to keep runtime compatibility to lowest runtime version available in target machine with similar characteristics (i.e. version 4.5), even the project compiled with newer version of .NET assemblies. The difference between version 4.5 and 4.6 is relatively small, thus keeping runtime version down to 4.5 still acceptable on this context.
Related references:
Application compatibility in the .NET
Framework
Retargeting Changes for Migration from .NET Framework 4.5 to
4.6
As per my understanding <compilation debug="true" targetFramework="4.6" /> is being suppressed by <httpRuntime targetFramework="4.5" /> since httpRuntime gets translated to following
<compilation targetFramework="4.5" />
<machineKey compatibilityMode="Framework45" />
<pages controlRenderingCompatibilityVersion="4.5" />
So above setting is probably due to some misunderstanding or a bug if done by VS directly which I don't believe is true.
To understand how this setting and all other related stuff means this blog titled All about <httpRuntime targetFramework> written by a Microsoft employee might help you. But the gist of it is;
The .NET Framework (including ASP.NET) strives to maintain near-100%
compatibility when an existing framework is updated on a machine. We
try to ensure as much as possible that if an application was developed
and deployed against .NET Framework 4, it will just continue to work
on 4.5. This normally means keeping quirky, buggy, or undesirable
behaviors in the product between versions, as fixing them may
negatively affect applications which were relying on those behaviors.
Strange ASP.Net Error (WebForms): .net 4.6.1, VS2015
Error BC36716 Visual Basic 12.0 does not support interpolated strings.
No clue why i'm getting this. Why is it reporting VB 12.0 under VS2015?
<system.web>
<compilation debug="true" strict="true" explicit="true" targetFramework="4.6.1"/>
<httpRuntime targetFramework="4.6.1"/>
</system.web>
Please look at the last answer at
http://forums.asp.net/t/2061764.aspx?VS2015+claims+it+does+not+support+interpolated+strings
Found the answer here if anyone else has the same problem. It looks
like the Roslyn compiler for Web Site project types is not icluded
with VS2015 and must be downloaded separately. See:
http://blogs.msdn.com/b/webdev/archive/2014/05/12/enabling-the-net-compiler-platform-roslyn-in-asp-net-applications.aspx
I hope it can help you.
I tried everything! Until this worked. I removed two packages I had installed from NuGet. Both of them where from Microsoft, one was a Roslyn package and the other was a compiler. When I took those out of my project all my errors about interpolated strings went away. I am running Visual Studio 2017.
So look through your packages and remove ones you do not need (maybe leftover from an old setup like I had)...
I hope this helps someone.
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.