.Net 3.5 Dll's in a .Net 4.0 application any issues

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 t开发者_JS百科he .net 3.5 code run in a different application pool?

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.

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.

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.

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.

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.

.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.