|
dev
newsgroups
|
|||||||||||||||||||||||
|
|||||||||||||||||||||||
Multiplatform & Interopinterop, the same binary should work well on32 bit, 64 bits and perhaps on the compact framework as well if I link against it. Now how could I achieve the same thing if I do interop and I have a managed C++ API? let say I have a managed C++ module compiled for 3 different target but with always the same interface: mycppmodule32.dll mycppmodule64.dll mycppmoduleCE.dll let say in the C# code I also do some interop internal class User32 // & CE ?! { [DllImport("USER32")] public IntPtr GetHdc(IntPtr hWnd); // 4 byte IntPtr } internal class User64 // not sure it exists, but I assume.... { [DllImport("USER64")] public IntPtr GetHdc(IntPtr hWnd); // 8 byte IntPtr } Let suppose these DLLs are included as modules in my csharpdll.dll. Now if I deploy all these DLLs, how could write a simple nice code in my C# dll which internally target whatever native lib is appropriate? Is it possible (to keep it simple)? -- Regards, Lloyd Dupont NovaMind development team NovaMind Software Mind Mapping Software <www.nova-mind.com> Hi Lloyd!
Consider preparing multiple builds of your C# dll for different platforms, using conditional compilation directives and constants to include the right DllImport attributes. Something like: #if WIN64 [DllImport("user64", ...] #else [DllImport("user32", ...] #endif Show quote "Lloyd Dupont" <net.galador@ld> wrote in message news:%23Ke4Q8AlGHA.4200@TK2MSFTNGP05.phx.gbl... > If I write a pure C# application, only using the standart publi API, no > interop, the same binary should work well on32 bit, 64 bits and perhaps on > the compact framework as well if I link against it. > > Now how could I achieve the same thing if I do interop and I have a > managed C++ API? > > let say I have a managed C++ module compiled for 3 different target but > with always the same interface: > mycppmodule32.dll > mycppmodule64.dll > mycppmoduleCE.dll > > let say in the C# code I also do some interop > internal class User32 // & CE ?! > { > [DllImport("USER32")] > public IntPtr GetHdc(IntPtr hWnd); // 4 byte IntPtr > } > internal class User64 // not sure it exists, but I assume.... > { > [DllImport("USER64")] > public IntPtr GetHdc(IntPtr hWnd); // 8 byte IntPtr > } > > > Let suppose these DLLs are included as modules in my csharpdll.dll. > > Now if I deploy all these DLLs, how could write a simple nice code in my > C# dll which internally target whatever native lib is appropriate? > Is it possible (to keep it simple)? > > > -- > Regards, > Lloyd Dupont > > NovaMind development team > NovaMind Software > Mind Mapping Software > <www.nova-mind.com> > Hi Dmytro,
Perhaps I didn't explained my self correctly. What I was trying to do in a simple manner (if possible) is to have one library to run them all! Like imagine my program is a click once application, I would like (if possible) to avoid the x32 link, the x64 link, the CE link. Just one link and it runs whatever the end-user machine. Or also imagine the user "install" (i.e. copy) the file on one PC, and then he simply copy the file again on an other PC and it still works! Conditional compilation is a clean way to have one build for each given platform. But I wonder if there is a no hassel way to have one build for all platform that the user could simply copy without worrying about his pc architecture.... Do you see what I mean? Is it possible? (in a simple way) For exemple a while back I wrote something like the code below so that my pocket application, using some WinCE specific dll, runs on both the desktop and CE smoothly. But it's kind of overkill for a big API. enum Platform { CE, Win32, } public class OSUtil { internal static Platform Platform { get {} } public int AMethod() { switch(Platform) { case CE: return OSUtilCE.AMethod(); case Win32: return OSUtilWin32.AMethod(); } } } class OSUtilCE { [DllImport("CEDll")] static int AMethodImpl(); static int AMethod() { return AMEthodImpl(); } } class OSUtil32 { [DllImport("Win32Dll")] static int AMethodImpl(); static int AMethod() { return AMEthodImpl(); } } Show quote "Dmytro Lapshyn [MVP]" <x-code@no-spam-please.hotpop.com> wrote in message news:%23fL8LUElGHA.4444@TK2MSFTNGP02.phx.gbl... > Hi Lloyd! > > Consider preparing multiple builds of your C# dll for different platforms, > using conditional compilation directives and constants to include the > right DllImport attributes. Something like: > > #if WIN64 > [DllImport("user64", ...] > #else > [DllImport("user32", ...] > #endif > > "Lloyd Dupont" <net.galador@ld> wrote in message > news:%23Ke4Q8AlGHA.4200@TK2MSFTNGP05.phx.gbl... >> If I write a pure C# application, only using the standart publi API, no >> interop, the same binary should work well on32 bit, 64 bits and perhaps >> on the compact framework as well if I link against it. >> >> Now how could I achieve the same thing if I do interop and I have a >> managed C++ API? >> >> let say I have a managed C++ module compiled for 3 different target but >> with always the same interface: >> mycppmodule32.dll >> mycppmodule64.dll >> mycppmoduleCE.dll >> >> let say in the C# code I also do some interop >> internal class User32 // & CE ?! >> { >> [DllImport("USER32")] >> public IntPtr GetHdc(IntPtr hWnd); // 4 byte IntPtr >> } >> internal class User64 // not sure it exists, but I assume.... >> { >> [DllImport("USER64")] >> public IntPtr GetHdc(IntPtr hWnd); // 8 byte IntPtr >> } >> >> >> Let suppose these DLLs are included as modules in my csharpdll.dll. >> >> Now if I deploy all these DLLs, how could write a simple nice code in my >> C# dll which internally target whatever native lib is appropriate? >> Is it possible (to keep it simple)? >> >> >> -- >> Regards, >> Lloyd Dupont >> >> NovaMind development team >> NovaMind Software >> Mind Mapping Software >> <www.nova-mind.com> >> > mhhhh....
perhaps I could still do as below but generate this wrapper code automatically? that's an idea! Show quote > enum Platform > { > CE, > Win32, > } > public class OSUtil > { > internal static Platform Platform { get {} } > > public int AMethod() > { > switch(Platform) > { > case CE: > return OSUtilCE.AMethod(); > case Win32: > return OSUtilWin32.AMethod(); > } > } > } > class OSUtilCE > { > [DllImport("CEDll")] > static int AMethodImpl(); > static int AMethod() { return AMEthodImpl(); } > } > class OSUtil32 > { > [DllImport("Win32Dll")] > static int AMethodImpl(); > static int AMethod() { return AMEthodImpl(); } > } > Well, you should be able to generate an "interop" assembly dynamically and
emit the IL code and the attributes on the fly. But it is much more headache than having a number of builds for different platforms. Show quote "Lloyd Dupont" <net.galador@ld> wrote in message news:ewuv28HlGHA.3776@TK2MSFTNGP03.phx.gbl... > mhhhh.... > > perhaps I could still do as below but generate this wrapper code > automatically? > that's an idea! > >> enum Platform >> { >> CE, >> Win32, >> } >> public class OSUtil >> { >> internal static Platform Platform { get {} } >> >> public int AMethod() >> { >> switch(Platform) >> { >> case CE: >> return OSUtilCE.AMethod(); >> case Win32: >> return OSUtilWin32.AMethod(); >> } >> } >> } >> class OSUtilCE >> { >> [DllImport("CEDll")] >> static int AMethodImpl(); >> static int AMethod() { return AMEthodImpl(); } >> } >> class OSUtil32 >> { >> [DllImport("Win32Dll")] >> static int AMethodImpl(); >> static int AMethod() { return AMEthodImpl(); } >> } >> > >
Show quote
"Lloyd Dupont" <net.galador@ld> wrote in message Hi Lloyd!news:%23Ke4Q8AlGHA.4200@TK2MSFTNGP05.phx.gbl... > If I write a pure C# application, only using the standart publi API, no > interop, the same binary should work well on32 bit, 64 bits and perhaps on > the compact framework as well if I link against it. > > Now how could I achieve the same thing if I do interop and I have a > managed C++ API? > > let say I have a managed C++ module compiled for 3 different target but > with always the same interface: > mycppmodule32.dll > mycppmodule64.dll > mycppmoduleCE.dll > > let say in the C# code I also do some interop > internal class User32 // & CE ?! > { > [DllImport("USER32")] > public IntPtr GetHdc(IntPtr hWnd); // 4 byte IntPtr > } > internal class User64 // not sure it exists, but I assume.... > { > [DllImport("USER64")] > public IntPtr GetHdc(IntPtr hWnd); // 8 byte IntPtr > } > > > Let suppose these DLLs are included as modules in my csharpdll.dll. > > Now if I deploy all these DLLs, how could write a simple nice code in my > C# dll which internally target whatever native lib is appropriate? > Is it possible (to keep it simple)? IntPtr is platform dependent, so in your sample, you don't have to declare twice. I know, this requires a lot of rereading docs before you can be sure, it works on both platforms. See also DMytro's answer. Hi,
"Lloyd Dupont" <net.galador@ld> wrote in message In the CF you have a VERY limited set of classes and methods inside the news:%23Ke4Q8AlGHA.4200@TK2MSFTNGP05.phx.gbl... > If I write a pure C# application, only using the standart publi API, no > interop, the same binary should work well on32 bit, 64 bits and perhaps on > the compact framework as well if I link against it. included classes, so the above is not 100% accurate. -- -- Ignacio Machin, ignacio.machin AT dot.state.fl.us Florida Department Of Transportation The trick, of course, is to build against the Compact CF.
Then it runs on the desktop! Do not worry for I have developed PocketPC application :-) Show quote "Ignacio Machin ( .NET/ C# MVP )" <ignacio.machin AT dot.state.fl.us> wrote in message news:euzdfCHlGHA.4508@TK2MSFTNGP05.phx.gbl... > Hi, > > > "Lloyd Dupont" <net.galador@ld> wrote in message > news:%23Ke4Q8AlGHA.4200@TK2MSFTNGP05.phx.gbl... >> If I write a pure C# application, only using the standart publi API, no >> interop, the same binary should work well on32 bit, 64 bits and perhaps >> on the compact framework as well if I link against it. > > In the CF you have a VERY limited set of classes and methods inside the > included classes, so the above is not 100% accurate. > > > > -- > -- > Ignacio Machin, > ignacio.machin AT dot.state.fl.us > Florida Department Of Transportation > Lloyd,
>Let suppose these DLLs are included as modules in my csharpdll.dll. Why do you want to deploy that way?Personally I would, if possible, have three builds of a single library mycppmodule.dll, and have the installer make sure the correct version gets installed on the system. That way a single set of DllImports can work on all platforms (assuming you can write all the signatures in a way that works everywhere). Mattias -- Mattias Sjögren [C# MVP] mattias @ mvps.org http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com Please reply only to the newsgroup. My problem is requiring an installer to have the library working seems
awfully overkill. I like the simple "xcopy" deployment method and I wonder if I could achieve it while being multiplatform... Well I huess it's not really pratical... Show quote "Mattias Sjögren" <mattias.dont.want.spam@mvps.org> wrote in message news:eR0aQVXlGHA.4792@TK2MSFTNGP02.phx.gbl... > Lloyd, > >>Let suppose these DLLs are included as modules in my csharpdll.dll. > > Why do you want to deploy that way? > > Personally I would, if possible, have three builds of a single library > mycppmodule.dll, and have the installer make sure the correct version > gets installed on the system. That way a single set of DllImports can > work on all platforms (assuming you can write all the signatures in a > way that works everywhere). > > > Mattias > > -- > Mattias Sjögren [C# MVP] mattias @ mvps.org > http://www.msjogren.net/dotnet/ | http://www.dotnetinterop.com > Please reply only to the newsgroup. Lloyd Dupont wrote:
> My problem is requiring an installer to have the library working seems Just in case you didn't check there:> awfully overkill. > I like the simple "xcopy" deployment method and I wonder if I could achieve > it while being multiplatform... > Well I huess it's not really pratical... I suggested a possible workaround in microsoft.public.dotnet.framework.interop,  |
|||||||||||||||||||||||
Other interesting topics