Linking problem

[Joerg M. Colberg]

I have a VS.Net solution that contains various projects. Some of the
projects contain programme blocks (legacy code) that are used by some of
the other projects.
One project contains some C code (managed and unmanaged) that uses
external libraries (GNU Scientific Library). These external libraries are
linked to in the Properties->Linker->Input page and the linking so far has
worked fine.
I just wrote a C# web application that references some of the other
projects incl. the project that I just mentioned. When I build the web
application, it copies over the dll's from the projects that are being
referenced by it but NOT the external libraries that are explicitely being
linked to in the C project that I described above. Does anybody know why? I
can copy the libraries by hand but I don't think that should be necesssary.
I also tried to reference those external libraries separately in the web
application project but that fails completely (I get an error "not a valid
assembly or COM component") - beats me why/how. So how do I make sure those
external libraries get copied and used properly?

- Joerg Colberg
([email protected])

 

[Guest]

Hi Joerge M. Colberg,

I am not that sure what you meant. I do assume this.

1) You had a big solution in .NET called ParentSolution.

2) 1 project that contains C# ASP.NET Web Application called SolutionA.

3) Inside the same ParentSolution, you had unmanaged C projects called SolutionB.

4) In SolutionB, you actually made references to other dlls or libs.

Overview:

ParentSolution
-> SolutionA
----> references to managed dll
-> SolutionB
----> link to unmanaged dll

Okay, actually i think you will have problems to get unmanaged C to work with .NET projects. 2 possible solution.

a) Port the SolutionB from C to Managed C++. But again there is still some problem, you had to port all possible dll to managed environment. Tough time.

b) From SolutionA, use platform invocation (P/INvoke - using dllimport) to call the SolutionB (make it a dll). Within SolutionB, it will reference other unmanaged dlls.

I had tried this way, and it works entirely fine in C# windows app.

My experiences:

MainSolution
--> C# Class Library
----> References to managed dll, like System or custom made managed libraries
----> Use P/Invoke to call c dll. In the c dll, actually i calls other dlls as well.
--> C# Windows App (tester app)

There might be some performance drop down. But it works fine.

Hope it works. Correct me if i am wrong. Thanks.

 

[Joerg M. Colberg]

Hi there,

I am not that sure what you meant. I do assume this.

1) You had a big solution in .NET called ParentSolution.
2) 1 project that contains C# ASP.NET Web Application called SolutionA.
3) Inside the same ParentSolution, you had unmanaged C projects called
SolutionB.

Well, almost. SolutionB is a managed C++ project that, however, calls
some unmanaged code (that lives in a dll). I'm not sure whether this
changes the solution you're suggesting.

b) From SolutionA, use platform invocation (P/INvoke - using dllimport) to
call the SolutionB (make it a dll). Within SolutionB, it will reference
other unmanaged dlls.

I'm assuming with the little change that I indicated above this
would be modified somehow, would it?
The problem also is not that the whole process doesn't work. The solution
builds fine when I run it using a little console application (also written
in C#). But when I integrate the whole thing into a C# webservie, the
unmanaged C code (the dll) doesn't get deployed properly.

Best,
Joerg