BorlandTalk.com

Mark Lamoreaux · Guest

Hi,

I'm trying to use a 3rd party .NET tool in Delphi 8 that was developed
for and tested with Visual Studio. The components are non-visual, so
I assume that I can use them in either a new VCL Forms application or
a Windows Forms application (if I try to import compenents from the
WinForms Control Import Wizard, it doesn't find any visual forms).

I went under Project->Add Reference and added the assembly file
FastObjects.t7.SDK.dll with the full path using the browse button in
the IDE. According to the error message when I tried to compile, it
was making a reference to another assembly,
FastObjects.t7.Runtime.dll, so I added this one the same way.

Now I'm getting the following error: [Error]File not found:
'FastObjects.t7.Runtime.Kernel.netmodule'. When I try to close the
project or exit Delphi, I get a popup error "File or assembly name
FastObjects.t7.SDK.Kernel.netmodule, or one of its dependencies, was
not found" and then access violations in coreide71.bpl until I end
task. Both of these files exist with the main assembly dll's. I've
also added their directory to the project's seach path and the main
environment library path. I even tried copying these netmodule files
to my project directory and I set their directory at the beginning of
my Windows Path statement, but still the same results.

I manually added the .netmodule files to project's source like the
assembly dll files, but then I get errors like "file not found: '
..dll'".

Is there another search path setting I'm missing or something else I
need to do to use a 3rd party .net assembly? Note, I also added the
namespace "FastObjects" to my uses clause of Unit1.pas. Is there a
reason why these .NET assemblies would work in VisualStudio and not
Delphi?

Thanks,
Mark

Mark Lamoreaux · Guest

Well, I've pretty much ruled out problems with the search
paths. It looks as though the .NET assemblies I'm using are
incompatible with Delphi. I was able to successfully compile them
into a project in Visual Studio, but when I reference them in to
Delphi, I get error messages as described above. Also, when it
reports that a referenced .dll was not found, the text in front of the
..dll is sometimes blank and sometimes full of non-printable
characters. Delphi then becomes unstable. I can look at the
properties of the assemblies after they've been referenced in to the
project and successfully view all of the information (i.e. uses,
classes, etc.), but it all breaks down when I go to compile.

It seems like the .dll assemblies were compiled with the
wrong/incompatible byte alignment or something. Is there a standard
for creating .NET assemblies? I believe these were created in Visual
C++. Are there different compiler settings that I can have the
original authors try to make them compatible with Delphi .NET?

Thanks,
Mark

Mark Lamoreaux · Guest

I apologize if this seems like a cross post to a similar thread I
started, but I believe I found the answer to why I've been having
these problems and didn't want to leave this thread hanging:

Apparently, the third party .NET tool I've been trying to use in
Delphi started as a mixture of J# and C# sources, and when you compile
an assembly from multiple sources, it creates a multiple file assembly
(.dll and .module). From what I understand, there's no way to
recompile this as a single file assembly (please correct me if I'm
wrong).

According to the engineers at FastObjects, there is currently a bug
(or limitation) in Delphi that prevents it from being able to properly
use multiple file assemblies. Is this true? If so, how does one go
about working with Borland to try and develop a patch for this, since
it seems to me that it is a major compatibility issue with .NET?

Thank you,
Mark

[email]markl (AT) cruzio (DOT) com[/email] (Mark Lamoreaux) wrote in message news:<bcc610ae.0405180907.41d96742 (AT) posting (DOT) google.com>...