.NET 2.0/.NET 1.1/Com Interop

**TheMonkey** · 14 August 2006, 16:22

You can mix them with no problems at all. I'd tend to make them portable between 1.1 and 2.0 and use the 1.1 runtime though to keep things as simple as possible. COM interop is generally total rubbish unless you're using VB.Net ironically.

Use msbuild to build against the 1.1 and 2.0 runtime and run any tests that are required.

**AtW** · 14 August 2006, 16:40

I'd recommend to reference them (1.1) as DLLS compiled in VS 2003 rather than put them into single build on VS 2005, which is possible but IMO best to keep those away so that they are never changed.

Check this link for breaking changes in .NET 2.0 - http://msdn.microsoft.com/netframewo...e/default.aspx

Overall its very compatible - but don't forget to have client requirement for .net 1.1 FX as otherwise your .net 1.1 dlls will be run by .net 2.0 FX.

**ASB** · 14 August 2006, 16:42

Cheers,

So it sounds as though I can intermingle with out too many funnies then. I'll try and knock up some tests and see what gives. Just wanted to make sure I wasn't embarking on a complete dead end before reading up on it and doing some tests.

Thanks.

**Cowboy Bob** · 15 August 2006, 05:31

To be honest, and I'm not a .NET person, if it didn't work between different versions that would be really bad planning and execution by MS. I'd have expected it to work. What "features" of .NET led you to believe it wouldn't? Just curious as I'm thinking about trying Mono out at some point in the future...

**TheMonkey** · 15 August 2006, 07:32

Originally posted by Cowboy Bob

To be honest, and I'm not a .NET person, if it didn't work between different versions that would be really bad planning and execution by MS. I'd have expected it to work. What "features" of .NET led you to believe it wouldn't? Just curious as I'm thinking about trying Mono out at some point in the future...

Nothing should be "forwards incompatible" if you design your software according to the automated code analysis tools like fxcop. The virtual machine apparently will in 20 years run the code that was developed now. COM interop is going to be phased out in the next few years as it is a legacy windows subsystem.

Mono is a good start. Try to avoid the GUI to start with as it's not quite set in stone what is happening. Also, mono is considerably slower than .Net as it runs a poor JIT rather than using complete JIT to compile to native code.

**ASB** · 15 August 2006, 08:06

Originally posted by Cowboy Bob

What "features" of .NET led you to believe it wouldn't?

Nothing specifically. Also I didn't suggest I believed it wouldn't - only looking for confirmation of any issues found.

However history is not exactly on MS side is it?

Transition through VB3/4/5/6 VB.NET for example. Various problems between MSC5, 6 and then movemoent forwards. Interaction with MSC and Watcom.

Huges problems with invoking dll's repackaged from C5 to C6 from (ahem) Micro Focus Cobol.

You could look at MS Cobol-80 and it's migration to a repackaged version of the Micro Focus compiler and then it's abandonment.

So, whilst .NET 1.1 had a great deal of abilitities in interop with other things it wouldn't surprise me to find some differences in 2.0 that caused incompatabilities, or at least certain effort.

**AtW** · 15 August 2006, 11:05

.NET 1.1 itself is a very much non-Microsoft job - no wonder since top guy who did C# was headhunted from Borland, he was like employee #4 there. .NET 2.0 is a good improvement, even though its really 1.2, but from compatibility point of view it seems very good: the only thing that struck me was changed behavior in case of unhandled exception in non-main thread - in .net 1.1 it would kill thread but thats it, where as in .net 2.0 it will kill whole app. Luckily its possible to use config to make it use old .net 1.1 behavior.

**ASB** · 15 August 2006, 11:16

An unhandled exception on the non main thread still goes to the installed unhandled exception handler (famous last words

). However I think this is only the case if its a thread you have created specifically.

If I recall correctly your problem was on an async read. In this case it doesn't go to the handler. How did you get round it in the end?

My pet hate for ages was not being able to update the UI from other than the main thread (except via invoke of course). I really don't see why the controls don't have a "Make safe" property to automate the calling from other threads when needed. Leaving it false can do it the direct way and true to check mustinvoke and use a delegate. Ok, you can do this yourself through inheritence but why should you need to.

**Cowboy Bob** · 15 August 2006, 12:11

Originally posted by AtW

the only thing that struck me was changed behavior in case of unhandled exception in non-main thread - in .net 1.1 it would kill thread but thats it, where as in .net 2.0 it will kill whole app.

Who's the idiot who thought that would be a good idea?

.NET 2.0/.NET 1.1/Com Interop