Re: .NET Assemblies and Search Paths

From: Mark Lamoreaux (markl_at_cruzio.com)
Date: 05/22/04

  • Next message: Skybuck Flying: "D7 IDE cries for code collaption ;)" 
    Date: 22 May 2004 11:47:57 -0700

    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

    markl@cruzio.com (Mark Lamoreaux) wrote in message news:<bcc610ae.0405180907.41d96742@posting.google.com>...
    > &#65279;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

  • Next message: Skybuck Flying: "D7 IDE cries for code collaption ;)"

    Relevant Pages

    • Re: general strong name question
      ... You have a project that compiles to a dll. ... Each time you recompile this assembly, and attempt to run the other apps, ... When you compile an assembly, ... assemblies) into the config files of the applications that use the ...
      (microsoft.public.dotnet.general)
    • Re: MSIL
      ... The pdb file is created when you compile your assembly with debugging ... dll or exe and is needed to debug assemblies at the source code level. ... If you have an example of output that does not compile, ...
      (microsoft.public.dotnet.languages.csharp)
    • Re: MSIL
      ... The pdb file is created when you compile your assembly with debugging ... dll or exe and is needed to debug assemblies at the source code level. ... If you have an example of output that does not compile, ...
      (microsoft.public.dotnet.languages.vb)
    • Re: MSIL
      ... The pdb file is created when you compile your assembly with debugging ... dll or exe and is needed to debug assemblies at the source code level. ... If you have an example of output that does not compile, ...
      (microsoft.public.dotnet.general)
    • Re: C# assembly in .NET Delphi Projects
      ... > the other is the Delphi project that have to "import" the firs one. ... In fact I have a Project group with several DLL projects, ... and only one Delphi application using the resulting assemblies. ... TeamBUG support for UK-BUG ...
      (borland.public.delphi.non-technical)
    Loading