Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
HomeAnnouncementsFree MagazinesWhite PapersSubmit Content
Discussion GroupsASP.NETWindows FormsLanguages.NET FrameworkVisual Studio.NET
Articles.NET FrameworkASP.NETToolsWindows Forms
.NET DirectoryOpen Source ProjectsUser GroupsWeb Resources
Related Topics
Visual Basic 6SQL ServerMS AccessOther DB ProductsMS Server ProductsMore Topics ...

.NET Forum / Languages / C# / October 2007

Tip: Looking for answers? Try searching our database.

LoadLibrary not working on Vista64?

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Peter Morris - 21 Oct 2007 07:44 GMT
I have a class named DynamicLinkLibrary which does this:

 [DllImport("kernel32.dll")]
 private static extern IntPtr LoadLibrary(string fileName);

 protected virtual void Load(string fileName)
 {
  EnsureNotDisposed();
  if (LibraryHandle != IntPtr.Zero)
   throw new InvalidOperationException("Library already loaded");
  if (string.IsNullOrEmpty(fileName))
   throw new ArgumentNullException(fileName);

  LibraryHandle = LoadLibrary(fileName);
  if (LibraryHandle == IntPtr.Zero)
   throw new InvalidOperationException("Invalid DLL file name: " +
fileName);
  FileName = fileName;
 }

In WinXP this works fine, however, when I run it on Vista the result of
LoadLibrary is always IntPtr.Zero.  Using a relative path (same folder) or
absolute path makes no difference.  Can anyone help?  This is stopping me
from migrating an app to Vista!

Thanks

Pete
Willy Denoyette [MVP] - 21 Oct 2007 08:44 GMT
>I have a class named DynamicLinkLibrary which does this:
>
[quoted text clipped - 24 lines]
>
> Pete

If you're trying to load a 32bit library, you'll need to target the "X86
platform" when compiling your code.

Note that you should check your error code when the LoadLibrary API call
fails.

[DllImport("kernel32.dll"), SetLastError=true]
...

If (LibraryHandle  == IntPtr.Zero)
   // Call Marshal.GetLastWin32Error to get the win32 error code.

Willy.
Peter Morris - 21 Oct 2007 10:15 GMT
Hi Willy

Thanks for the answer!

I didn't know that I cannot use LoadLibraryEx in Win64 to load a 32 bit dll!
This is how my app is structured, each project depends upon the one above:

DynamicLinkLibrary in DynamicLinkLibrary.dll
FortranDynamicLinkLibrary in FortranDynamicLinkLibrary.dll
MySpecificDLL in MySpecificDLL.dll (dynamically loads 3rdparty.dll)
MyApp.exe

I've now set the Target Platform of MyApp.exe to x86 and it works perfectly.
Are there any negative points to doing this?

Thanks very much for your help, I really appreciate it!

Pete
Willy Denoyette [MVP] - 21 Oct 2007 10:27 GMT
> Hi Willy
>
[quoted text clipped - 3 lines]
> dll! This is how my app is structured, each project depends upon the one
> above:

You can not load a 32bit DLL into a 64bit process. A Managed application
built with AnyCPU (MSIL) as target, will load the 64bit CLR and as such run
as a 64bit process.

> DynamicLinkLibrary in DynamicLinkLibrary.dll
> FortranDynamicLinkLibrary in FortranDynamicLinkLibrary.dll
[quoted text clipped - 3 lines]
> I've now set the Target Platform of MyApp.exe to x86 and it works
> perfectly. Are there any negative points to doing this?

No, your program runs as a 32bit process under Wow64 on 64bit Windows. The
performance impact of the transition into the 64bit kernel is extremely low,
and is completely compensated by the lower CPU cache pressure.
That means that your code in general runs as fast as it would be compiled as
64 bit.

Willy.
Peter Morris - 21 Oct 2007 10:58 GMT
Excellent, thankyou so much for your help!

Free Magazines

Get these publications absolutely FREE for up to 12 months. There are no hidden fees and no obligation. Simply choose a title, complete the application form and submit it. Read more ...

Oracle MagazineNetwork ComputingComputer WorldBio-IT WorldeWeekInformation WeekInfosecurity
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.