Home Help Center

IceBoxNet and managed c++ assembly

jonpjonp Member Jon PetittaOrganization: GFI inc.Project: Distributed Task Framework
Windows 7 x64
Visual Studio 2010 (C++/CLR Class Assembly project targeting .NET 3.5)
Ice 3.4.1

I was wondering if anyone had any experience with, or know if it is possible to create an IceBox service in Managed C++ (C++/CLI)?

I followed the examples in the manual for creating a C# service, porting it to managed C++.

When I attempt to load it into iceboxnet I get the following error message.

Could not load file or assembly 'foo.dll' or one of its dependencies. The system cannot find the file specified.

More often than not this error is caused by some dependency of foo.dll, but MS decided to leave that little piece of data out of the exception. They want to make you work for it by implementing a ResolveEventHandler.

TIA,
Jon

Comments

  • GravitasGravitas Member Shane TolmieOrganization: Software HouseProject: Server modules in C++, C# and Java, to client. ✭✭
    I ran into exactly the same combination of errors.

    You can only load assemblies compiled with "All CPU" into Icebox. My .dll was compiled in x32 mode, so it wouldn't load and gave this exact error.

    In addition, you can't load assemblies compiled with .NET 4.0 into Icebox, unless you configure iceboxnet.exe to run under .NET 4.0 by adding the following file "iceboxnet.exe.config" to the same directory as "iceboxnet.exe":

    <?xml version=”1.0”?>
    <configuration>
    <startup>
    <supportedRuntime version=”v4.0” />
    </startup>
    </configuration>

    I'm currently using C# managed assemblies within iceboxnet.exe, and it works brilliantly.

    Every single person will run into this problem unless the error messages in iceboxnet.exe are improved. I've posted a bug report to Zeroc.
  • jonpjonp Member Jon PetittaOrganization: GFI inc.Project: Distributed Task Framework
    That is the thing, I am targeting .NET 3.5 (verified output with depends.net). This is a C++ project, so the only build config is Win32. I do not know where the 'all cpu' option is, but I am familiar with a C# build option called 'any cpu', which will just compile an assembly to either x32 or x64 depending on the platform it is being built on. If the build config was incorrect, .NET should throw the following exception, BadImageFormatException (I am using the x32 version of ICE), but the only thing being reported is a FileNotFound exception while performing an Assembly.Load.

    I know it does work in a straight language mapping config, C++ IceBox with a C++ IceBox::Service, or C# IceBoxNet with a C# IceBox.Service. I'm trying to see if it's possible to load a C++/CLI IceBox.Service (.NET) into the C# IceBoxNet host. We have quite a bit of managed code that calls native code, and we have various interop layers, some of which involves using C++/CLI wrappers for Native code in the same Assembly. It just would have been nice to not have to put another layer in between Ice and the Mixed Assemblies.
  • GravitasGravitas Member Shane TolmieOrganization: Software HouseProject: Server modules in C++, C# and Java, to client. ✭✭
    My two cents worth:

    A C++/CLI assembly is really just a .NET assembly, so it should load into iceboxnet. Have a look at the top of the screen where you select "Debug" or "Release" and select "Manage configurations", then set it to compile the .dll to "All CPU". This means that if the host OS is 64-bit, it will load the 64-bit version of the .NET .dll, and if the host OS is 32-bit, it will still work by loading a 32-bit version from the same .dll.

    For comparison, try loading up the Icebox demo, and set the project type to generate a 32-bit .NET .dll. It will fail with the error you described.

    Regarding architecture: I've written a few mixed mode C++/CLI wrappers to allow C++ to call .NET, and although it worked it difficult and error prone, especially if you have deeply nested structures with collections. The latest solution I have was to abandon the mixed mode wrapper .dll and use ICE for all inter language comms.
Sign In or Register to comment.