.NET dealing with unmanaged environment

If you ask a programmer, what is for the job for developing of a code which isn’t a reason of headache, he’ll answer – it is managed code and .NET Framework.As a matter of fact, .Net provides low input from development to maintenance.

Nevertheless, everyone should remember about one very serious generic problem of managed code.It involves inadequacy with unmanaged environment.This is followed by plenty of troubles while working with managed code in unmanaged environment.What’s to be done?

Is there a way out?

Yes, there is.Yet, there are more than one.These solutions arouse panic attacks among C# and especially VB.NET developers, but they are rather normal for .NET.Moreover, you mustn’t be a guru developer to use them.During the work with unmanaged code in managed you may apply such mechanisms as P/Invoke, COM Interop and Unsafe.Choosing one of these methods you should keep in mind their two fundamental defects.

– Firstly, before code fetching you must identify operation embracing in application manifest.

– Secondly, unmanaged code has no security and does not pass CLR checks.In other words, unmanaged function will be executed, even if you define a rule “to bar access to files”.

The variant of work with managed code in unmanaged is less optimistic.Much more problems arise in this case.

– COM-objects written in .NET claim registration by Regasm, which complicates installers development.

– One more disadvantage of ComExport is impossibility to create Out-Process COM.

– Thereto, created components must be approved (even with temporary key) or registration in GAG by Gacutil.This is impossible without administrator rights in Windows Vista.

– While using the components CLR are loaded to the address space of the calling process.

About Coherent Solutions: technology consulting,java web & application development company.

Author: Coherent Solutions

Leave a Reply

Your email address will not be published.