-
July 1st, 2010, 08:11 AM
#1
Dllimport: Change dll-name from case to case?
Hi!
I would like to know if it is possible to use DLLimport in that way, that I can decide between
two cases, e.g. 32 bit OS or 64 bit OS.
Pseudo code:
Code:
if (OS_Is32)
{
DLLimport("32bit.dll")....
}
if (OS_Is64)
{
DLLimport("64bit.dll").....
}
I know that I cannot use such if-conditions, but... is there any way I can solve my issue??
-
July 1st, 2010, 08:32 AM
#2
Re: Dllimport: Change dll-name from case to case?
-
July 1st, 2010, 08:37 AM
#3
Re: Dllimport: Change dll-name from case to case?
Thanks!
But: How can I check the OS before the pre-processor runs?
I need at least a bool flag which says: IS_64 (tru/false).
So this I could use in that #if.....
-
July 1st, 2010, 08:42 AM
#4
Re: Dllimport: Change dll-name from case to case?
Well, to determine if the OS is either 64 bit or 32 bit, all you have to do is to test the size of IntPtr, like this :
Code:
if (System.IntPtr.Size == 8)
{
// 64-bit
}
else
{
// 32-bit
}
Inside there, you could set your OS_Is32 to true or false, then you don't need the IS_64 variable.
Then, use your #if statements to test for Os_Is32 and do whatever
Understand?
-
July 1st, 2010, 08:44 AM
#5
Re: Dllimport: Change dll-name from case to case?
Oooh, so close
Code:
[DllImport ("lib32.dll")]
public static extern int Some32BitMethod (int value);
[DllImport ("lib64.dll")]
public static extern int Some64BitMethod (long whatever);
public int CallMethod ()
{
if (IntPtr.Size == 8) // Assume 64bit pointer is a 64bit system
return Some64BitMethod ();
else
return Some32BitMethod ();
}
Done and done. A better approach may be to create an interface and have two subclasses. One subclass calls the 32bit methods, the other calls the 64bit method. At runtime you just use the correct class. This would be the 'recommended' approach.
www.monotorrent.com For all your .NET bittorrent needs
NOTE: My code snippets are just snippets. They demonstrate an idea which can be adapted by you to solve your problem. They are not 100% complete and fully functional solutions equipped with error handling.
-
July 1st, 2010, 08:46 AM
#6
Re: Dllimport: Change dll-name from case to case?
Originally Posted by HanneSThEGreaT
Code:
if (System.IntPtr.Size == 8)
{
// 64-bit
}
else
{
// 32-bit
}
Inside there, you could set your OS_Is32 to true or false, then you don't need the IS_64 variable.
Then, use your #if statements to test for Os_Is32 and do whatever
Except that #if are compile time pre-processor statements and what you've written there is normal C# code which is only evaluated at runtime. The above can't possibly work.
www.monotorrent.com For all your .NET bittorrent needs
NOTE: My code snippets are just snippets. They demonstrate an idea which can be adapted by you to solve your problem. They are not 100% complete and fully functional solutions equipped with error handling.
-
July 1st, 2010, 09:01 AM
#7
Re: Dllimport: Change dll-name from case to case?
OK, My name is Mr. Stupid today, or I'll also go with HanneSThEStupiD !
I guess I was working with Preprocessor Directives in VC++ for too long. I still think though there is an inbuilt constant for this. MNovy, I humbly apologise ( lack of sleep ), please forget my idea about the #if's etc. but the advice in post 4 and 5 should be all you need.
Second time today I make a boo boo!, I guess I should go home and get some sleep
-
July 4th, 2010, 11:37 PM
#8
Re: Dllimport: Change dll-name from case to case?
Thanks for your answers so far.
So, if using Interfaces, how do I manage the right instantiation of the correct class implementation at start-up, according to the operating system (32 bit/64 bit), when the code is running?
Pseudocode
Code:
Interface
{
Methode_A();
Methode_B();
}
Class 32_Bit:Interface
{
DLLimport("my32-bit.dll");
.....
DLLimport("my32-bit.dll");
.....
DLLimport("my32-bit.dll");
.....
DLLimport("my32-bit.dll");
.....
Methode_A()
{
return 32;
}
Methode_B()
{
return33;
}
}
Class 64_Bit:Interface
{
DLLimport("my64-bit.dll");
.....
DLLimport("my64-bit.dll");
.....
DLLimport("my64-bit.dll");
.....
DLLimport("my64-bit.dll");
.....
Methode_A()
{
return 64;
}
Methode_B()
{
return64;
}
}
Last edited by MNovy; July 5th, 2010 at 12:30 AM.
-
July 5th, 2010, 12:35 AM
#9
Re: Dllimport: Change dll-name from case to case?
One way is to put all your platform specific code into an assembly (actually 2 assemblies: one for 32-bit and one for 64-bit).
Then in the main assembly, call load library on the appropriate assembly.
-
July 5th, 2010, 01:18 AM
#10
Re: Dllimport: Change dll-name from case to case?
Originally Posted by Arjay
One way is to put all your platform specific code into an assembly (actually 2 assemblies: one for 32-bit and one for 64-bit).
Then in the main assembly, call load library on the appropriate assembly.
The problem I have is the part of calling/instantiation of the right class on runtime.
I am still looking for a way to figure out the operating system (32 bit or 64 bit) and load
the correct DLLs in advance.
The assembly I develop is used by another programmer, and I want to deliver the right
class with the right DLLimports (32 bit or 64 bit) on runtime....
In other words:
If the programmer calls "MyClass test" under 32 bit Windows,
MyClass should be implemented with "DLLimports 32bit.dll"
And if the programmer calls "MyClass test" under 64 bit Windows,
MyClass should be implemented with "DLLimports 64bit.dll"
I have absolutely no idea how to solve this. :-(
-
July 5th, 2010, 01:39 AM
#11
Re: Dllimport: Change dll-name from case to case?
Ok, I think I have a good solution now. Can anyone confirm this concept?
Is the instantiation of an interface inside a class a no-go?
Interface
Code:
interface Interface1
{
int ReturnValue();
}
1st implentation
Code:
class Class1:Interface1
{
[DllImport(@"32bit.dll", EntryPoint = "test")]
public static extern int _ReturnValue();
public int ReturnValue()
{
Console.WriteLine("Test: " + _ReturnValue());
return 1;
}
}
2nd implentation
Code:
class Class2:Interface1
{
[DllImport(@"64bit.dll", EntryPoint = "test")]
public static extern int _ReturnValue();
public int ReturnValue()
{
Console.WriteLine("Test: " + _ReturnValue());
return 1;
}
}
Delivered class (used by external programmer)
Code:
class Class
{
public Interface1 intf;
public Class()
{
if (System.IntPtr.Size == 8)
{
intf = new Class2(); // 64 bit
}
else
{
intf = new Class1(); // 32 bit
}
}
}
Example call by external programmer
Code:
namespace ConsoleApplication1
{
class Program
{
static void Main(string[] args)
{
Class c = new Class();
Console.WriteLine(c.intf.ReturnValue());
Console.Read();
}
}
}
Is that design okay? It works, at least...
Last edited by MNovy; July 5th, 2010 at 01:57 AM.
-
July 5th, 2010, 04:31 AM
#12
Re: Dllimport: Change dll-name from case to case?
Yeah, that's pretty much what I was suggesting. However you could make it a bit cleaner by doing this:
Code:
class Class : Interface1
{
Interface1 actual;
public Class ()
{
if (System.IntPtr.Size == 8)
{
actual = new Class2(); // 64 bit
}
else
{
actual = new Class1(); // 32 bit
}
}
public int ReturnValue()
{
return actual.ReturnValue ();
}
}
Make the 64bit and 32bit implementation internal/hidden to the user of your application and just give him a 'MyClass' which implements the same interface. Then they can use everything normally without strange levels of indirection and automagically end up calling the 32bit or 64bit implementation as appropriate.
www.monotorrent.com For all your .NET bittorrent needs
NOTE: My code snippets are just snippets. They demonstrate an idea which can be adapted by you to solve your problem. They are not 100% complete and fully functional solutions equipped with error handling.
-
July 5th, 2010, 12:49 PM
#13
Re: Dllimport: Change dll-name from case to case?
Originally Posted by MNovy
The problem I have is the part of calling/instantiation of the right class on runtime.
I am still looking for a way to figure out the operating system (32 bit or 64 bit) and load
the correct DLLs in advance.
The assembly I develop is used by another programmer, and I want to deliver the right
class with the right DLLimports (32 bit or 64 bit) on runtime....
I don't have much dog in this fight, but you can still use what I suggested. You deliver 3 assemblies: a user called assembly and two platform specific assemblies. The user called assembly wraps the functionality, detects the OS, which then loads the proper platform specific assembly to implement the functionality. I'm not saying this is the way to go in your case, but it is another option.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|