Unmanaged DLLs?

  • Thread starter Thread starter James Hunter Ross
  • Start date Start date
J

James Hunter Ross

Friends,

Do any of your ASP.NET applications make use of unmanaged DLLs? We wrote
"managed C++" wrappers to some MFC-based APIs that our company wrote, and it
all works... except maybe sometimes not! We are not sure yet where the
trouble is, so I thought perhaps I could get a feel for how common/uncommon
such an implementation is today.

Any words will be very much appreciated. Thanks in advance! James
 
Friends,

Do any of your ASP.NET applications make use of unmanaged DLLs?  We wrote
"managed C++" wrappers to some MFC-based APIs that our company wrote, andit
all works... except maybe sometimes not!  We are not sure yet where the
trouble is, so I thought perhaps I could get a feel for how common/uncommon
such an implementation is today.

Any words will be very much appreciated.  Thanks in advance!   James
Click to expand...

Have you looked at pInvoke? A good resource to look at is http://www.pinvoke.net,
you might run into permission issues depending on where the dll's are
located.
 
Friends,

Do any of your ASP.NET applications make use of unmanaged DLLs?  We wrote
"managed C++" wrappers to some MFC-based APIs that our company wrote, andit
all works... except maybe sometimes not!  We are not sure yet where the
trouble is, so I thought perhaps I could get a feel for how common/uncommon
such an implementation is today.

Any words will be very much appreciated.  Thanks in advance!   James
Click to expand...

Have you looked at pInvoke? A good resource to look at is http://www.pinvoke.net,
you might run into permission issues depending on where the dll's are
located.
 
Hello James,
Friends,

Do any of your ASP.NET applications make use of unmanaged DLLs? We
wrote "managed C++" wrappers to some MFC-based APIs that our company
wrote, and it all works... except maybe sometimes not! We are not
sure yet where the trouble is, so I thought perhaps I could get a feel
for how common/uncommon such an implementation is today.

Any words will be very much appreciated. Thanks in advance! James
Click to expand...


managed wrappers around C++ code are a pretty useful technique to enable
code reuse and to prevent having to re-write loads of available legacy stuff.
But... If you consider moving forward on the .NET side of things I'd choose
to slowly migrate existing code when parts of them need an update anyway.

Having managed and unmanaged code working together, is a hassle and is differcult
to do right. It's easier in the long run to try and lose the legacy stuff
along the way ;).
 
Hello James,
Friends,

Do any of your ASP.NET applications make use of unmanaged DLLs? We
wrote "managed C++" wrappers to some MFC-based APIs that our company
wrote, and it all works... except maybe sometimes not! We are not
sure yet where the trouble is, so I thought perhaps I could get a feel
for how common/uncommon such an implementation is today.

Any words will be very much appreciated. Thanks in advance! James
Click to expand...


managed wrappers around C++ code are a pretty useful technique to enable
code reuse and to prevent having to re-write loads of available legacy stuff.
But... If you consider moving forward on the .NET side of things I'd choose
to slowly migrate existing code when parts of them need an update anyway.

Having managed and unmanaged code working together, is a hassle and is differcult
to do right. It's easier in the long run to try and lose the legacy stuff
along the way ;).
 
the main issue with unmanaged dll's from asp.net is threading.

be sure statics are properly handled via locks.

also in asp.net you can not use thread local storage (its not consistant
through the request) . if you do, then you need to create dedicated
threads to access the dll's.

if the dll's com objects, then they should be free threaded, not sta. if
they are sta you need to use aspcompat mode.

-- bruce (sqlwork.com)
 
the main issue with unmanaged dll's from asp.net is threading.

be sure statics are properly handled via locks.

also in asp.net you can not use thread local storage (its not consistant
through the request) . if you do, then you need to create dedicated
threads to access the dll's.

if the dll's com objects, then they should be free threaded, not sta. if
they are sta you need to use aspcompat mode.

-- bruce (sqlwork.com)
 
Back
Top