Force references to run against .NET 1.1

[Dave Booker]

I am developing in VS2005, but I have some third-party DLL's that appear to
only work correctly when compiled in VS2003. ("Incorrect" operation is
defined as a busy-wait that kicks in on a message loop, hogging a full CPU
thread even when nothing is happening.)

I am assuming the difference is that the DLL's were compiled for .NET 1.1.
What are my options for compiling in VS2005 but running the DLL's against the
1.1 framework? My own code makes extensive use of C# generics and so I'm
assuming would only work against .NET 2.0?

[Tom Porterfield]

Dave Booker wrote:

I am developing in VS2005, but I have some third-party DLL's that appear
to only work correctly when compiled in VS2003. ("Incorrect" operation is
defined as a busy-wait that kicks in on a message loop, hogging a full CPU
thread even when nothing is happening.)

I am assuming the difference is that the DLL's were compiled for .NET 1.1.
What are my options for compiling in VS2005 but running the DLL's against
the
1.1 framework? My own code makes extensive use of C# generics and so I'm
assuming would only work against .NET 2.0?

My understanding is that the dll's will execute under whatever version of
the framework that the owning process is executing under. So if your app is
running under 2.0 and you are loading the referenced dlls in your app, then
they too will run under 2.0.

You would need to either come up with some way of leveraging the
functionality in the 3rd party components remotely, in a separate app that
runs under 1.1, or contact the supplier about obtaining a 2.0 compatible
version of the dll's.
--
Tom Porterfield

[Dave Booker]

My understanding is that the dll's will execute under whatever version of
the framework that the owning process is executing under. So if your app is
running under 2.0 and you are loading the referenced dlls in your app, then
they too will run under 2.0.
How can I determine/force which framework a process should execute under?
You would need to either come up with some way of leveraging the
functionality in the 3rd party components remotely, in a separate app that
runs under 1.1, or contact the supplier about obtaining a 2.0 compatible
version of the dll's.

Sounds reasonable. So how can I force that separation? E.g., if I could
compile the components I want running in 1.1, how could I reference them from
a 2.0 process while running them in 1.1? With a System/Commandline call from
the 2.0 process? What are my options?
1. If I compile the DLL's into a separate

[Tom Porterfield]

Dave Booker wrote:

My understanding is that the dll's will execute under whatever version of
the framework that the owning process is executing under. So if your
app is running under 2.0 and you are loading the referenced dlls in your
app, then they too will run under 2.0.

How can I determine/force which framework a process should execute under?

You can force your app to run under a specific version of the framework, but
if you are using generics then it won't work. For more info on how to
target a specific framework version, see the following article:

How to: Use an Application Configuration File to Target a .NET Framework
Version
http://msdn2.microsoft.com/en-us/library/9w519wzk.aspx

Also some discussion at http://channel9.msdn.com/Showpost.aspx?postid=73151.

You would need to either come up with some way of leveraging the
functionality in the 3rd party components remotely, in a separate app
that runs under 1.1, or contact the supplier about obtaining a 2.0
compatible version of the dll's.

Sounds reasonable. So how can I force that separation? E.g., if I could
compile the components I want running in 1.1, how could I reference them
from a 2.0 process while running them in 1.1? With a System/Commandline
call from the 2.0 process? What are my options?
1. If I compile the DLL's into a separate

Command line is an option. You could also use a remoting or webservice
call.
--
Tom Porterfield

[Dave Booker]

Shoot, so I have a program that is very tightly coupled to .NET 2.0, and I
have these DLL's that define objects that only work in .NET 1.1.

I understand that with remoting I could run the DLL objects in a separate
process from the main code.

But is there anything that could save me the hassle of remoting? For
example, could I instantiate the DLL objects in a thread that runs against
the 1.1 framework while the main program thread runs against 2.0?

Sounds reasonable. So how can I force that separation? E.g., if I could
compile the components I want running in 1.1, how could I reference them
from a 2.0 process while running them in 1.1? With a System/Commandline
call from the 2.0 process? What are my options?
1. If I compile the DLL's into a separate

Command line is an option. You could also use a remoting or webservice
call.
--
Tom Porterfield

[Jeffrey Tan[MSFT]]

Hi dbooksta,

Thanks for your post!

Unfortunately, .Net does not support loading 2 different versions of CLR in
the same process, please refer to the link below for more information:
"CLR Side by Side and Compatibility"
http://blogs.msdn.com/junfeng/archiv...26/422014.aspx

Normally .Net2.0 has considered .Net1.1 backward compatibility in design,
so .Net1.1 code should work well in .Net2,.0 runtime. Therefore I do not
understand why that 3rd party dll will have slow performance hang in
message loop. In this scenario, you'd better contact that 3rd party vendor
for a .Net2.0 compatible version of dll as "Tom Porterfield" suggested.
Otherwise, the possible workaround in .Net is using .Net remoting or
WebService to isolate the dll from the exe.

Hope this helps!

Best regards,
Jeffrey Tan
Microsoft Online Community Support
==================================================
When responding to posts, please "Reply to Group" via your newsreader so
that others may learn and benefit from your issue.
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.