5

We are planning to move a legacy application which uses enterprise library 4.1 which uses .Net 3.5 in a .Net 4.0 web application.

We are wondering will this cause any performance problems? Will the .net 3.5 code run in a different application pool?

skaffman
  • 398,947
  • 96
  • 818
  • 769
Shiraz Bhaiji
  • 64,065
  • 34
  • 143
  • 252

6 Answers6

5

I have finally found answer to this. The performance problem I previously mentioned my team discovered is due to something else. Not loading .NET 3.5 on .NET 4.0 App Domain.

Reading this article: http://msdn.microsoft.com/en-us/magazine/ee819091.aspx

In-Proc SxS does not solve the compatibility problems faced by library developers. Any libraries directly loaded by an application--either via a direct reference or an Assembly.Load--will continue to load directly into the runtime and AppDomain of the application loading it. This means that if an application is recompiled to run against the .NET Framework 4 runtime and still has dependent assemblies built against .NET 2.0, those dependents will load on the .NET 4 runtime as well. Therefore, we still recommend testing your libraries against all version[s] of the framework you wish to support. This is one of the reasons we have continued to maintain our high level of backward compatibility.

So, there's no problem loading .NET 3.5 assemblies directly into .NET 4.0 apps without recompiling them into .NET 4.0.

oazabir
  • 1,599
  • 9
  • 15
1

4.0 is a superset of 3.5 so there should be no challenges. All of you 3.5 code will work as it had when built with VS 2008. You need to follow this first
There is a MSDN link What's New in the .NET Framework 4
Migration Guide to the .NET Framework 4
.NET Framework 4 RTM Application Compatibility Walkthrough

If you do a Google search you'll find many articles titled something like "What's new in 2010". You won't find things like "What's Different"

Except for this little tidbit From MSDN:

The .NET Framework 4 is highly compatible with applications that are built with earlier .NET Framework versions, except for some changes that were made to improve security, standards compliance, correctness, reliability, and performance.

The .NET Framework 4 does not automatically use its version of the common language runtime to run applications that are built with earlier versions of the .NET Framework. To run older applications with .NET Framework 4, you must compile your application with the target .NET Framework version specified in the properties for your project in Visual Studio, or you can specify the supported runtime with the Element in an application configuration file.


Amit
  • 21,570
  • 27
  • 74
  • 94
  • 3
    -1: "so there should be no challenges. All of you 3.5 code will work as it had when built with VS 2008": The list of breaking changes is actually long, see here for an entry point to the various .NET technologies: [.NET4 Complete List of Breaking Changes](http://muneebbaig.blogspot.com/2010/04/net4-complete-list-of-breaking-changes.html). In general, any change in a product including change of the .NET runtime environment should be accompanied by heavy testing. – Dirk Vollmar May 18 '11 at 21:04
1

You question whether there will be performance issues cannot be generally answered as it depends on what your code is doing. Most likely you won't see any issues.

Although Microsoft did a lot to remain backwards compatible with the previous version of the runtime you should be aware that there are several breaking changes. You will find them documented in MSDN here:

.NET Framework 4 Migration Issues (including documentation on ASP.NET, .NET Core, Data/ADO.NET, WCF, WPF and XML)

Microsoft also provides guidance and links to further migration planning tasks:

Migration Guide to the .NET Framework 4

As you should be prepared for any issues, don't forget to schedule some time for additional testing.

Dirk Vollmar
  • 172,527
  • 53
  • 255
  • 316
1

Plan to do you own perf testing. For guidance, see this from the patterns & practices.

I don't know which blocks you are using, but you should consider migrating to EntLib v5.0, since there were major perf improvements in the logging application block as well as a refactoring/cleanup of the underlying infrastructure. Check out the Migration Guide for Enterprise Library 5.0.

Grigori Melnik
  • 4,067
  • 2
  • 34
  • 40
0

Well it shouldn't have any performance problems. However, one major difference is that .Net 4.0 comes with a different runtime which may introduce some differences.

Brian S.
  • 405
  • 3
  • 10
-1

.NET 3.5 DLLs are loaded in separate app domain than .NET 4. So, all calls to .NET 3.5 DLLs from .NET 4 will be across app domain. That means quite some overhead. Unless you can rebuild the 3.5 source code in .net 4, I would not recommend using it. One of my team tried that and then they saw pretty bad performance so they went back to .NET 3.5. Until we get source code for all .net 3.5 DLLs or vendors release .net 4 DLLs we aren't going to upgrade our code base to net 4.

oazabir
  • 1,599
  • 9
  • 15
  • 1
    Do you have any references for this? – Shiraz Bhaiji May 23 '11 at 17:20
  • Based on my experience so far I was hoping that Omar may be correct but after firing up Process Exprlorer and taking a look I only see two AppDomains loaded "SharedDomain" and "DefaultDomain" and I don't see any evidence that only the 3.5 assemblies are being loaded in one of the domains. Instead All assemblies other than mscorlib are loaded into the DefaultDomain. More details here http://msdn.microsoft.com/en-us/magazine/cc163791.aspx#S4 – jpierson Apr 20 '12 at 14:39