1

Our application is composed of mixed C# / managed C++ CLI / native C++ assemblies & DLLs.

We have a wrapper assembly that exposes the application's API.

FOR EXAMPLE...to create new console applications that use the API, you must reference that assembly, and also set the console application's output directory to the BIN directory of our installed application. ( due to the use of reflection, etc., everything must stay in the app's BIN directory and output to that directory, you cannot do a copy local of just the one assembly or nothing works )

My issue is when creating an ASP.NET web forms application (nothing to do with the console app), I would like to use that assembly, so I need the web application to "live" in our application's BIN directory.

When I try that errors occur due to ASP.NET trying to preload every single assembly in that BIN directory.

Can someone provide instructions on how to get this to work? I've spent hours now on every combination of referencing assemblies, copying them all, and trying to use LoadFrom.

Darrin Doherty
  • 840
  • 1
  • 6
  • 17
  • 2
    Without seeing what appears to be a completely cluster f**k of a design its going to be really hard to help you. I would highly encourage you to talk to the designer of this. – NotMe Jun 24 '13 at 18:13
  • Thanks, but the app has been around for 20 years now and is very successful. – Darrin Doherty Jun 24 '13 at 18:14
  • 3
    Just because something has been around for a long time doesn't make the design good. Actually, it makes it more likely that there have been a LOT of choices made which preclude doing what you want to do. – NotMe Jun 24 '13 at 18:17
  • I agree, I was just trying to say that a redesign will be very hard to sell. – Darrin Doherty Jun 24 '13 at 18:18
  • 1
    I think everyone has had to work with applications that are ... well less than optimal. I've a lot of sympathy for Darren.Let me tell you about one application I had to work with 10000 methods, completely broken page model rant rant rant rant – Crab Bucket Jun 24 '13 at 18:22
  • I actually wasn't advocating a rewrite. I was trying to say that you should talk to the people that built this and see what ideas they have. – NotMe Jun 24 '13 at 22:13

1 Answers1

1

Without seeing the construction of this it's hard but ...

Bin referencing

Create a web application and reference the necessary dll from the web site via bin references

Right click the web application, select the browse option and pcik the dlls you need to reference. Select copy local to true so you get the dll copied through to the web application so you aren't forever dependent on the console app being exactly where it needs to be in relation to the web app.

Not a solution I would necessarily go with though - it seems like the arcitecture of the system is a little off. Cross you have to bare etc...

OR

GAC referencing

the dlls that you need to reference from the console app - strongly name them and put them in the GAC (global assembly cache). Both apps will be able to see them then.

Copy over the dll

I guess there is another solution around adding a post build step to the console app that reruns a batch file that will copy over the dlls into the web app. I think that's going to be pretty much the same as the bin reference though really.

Probing element

You could use a <probing> element in your web.config to instruct the CLR to search for other directories for assembles (it normally just does the GAC and bin (a simplification to be fair is that) ). This is going to enable you to reference your API folder - but only if it is under your application path. Although someone here has used an NFTS junction to get around this.

More info here

In fact this answer gives a lot more detail about this kind of thing

How do I reference assemblies outside the bin folder in an ASP.net application?

And good luck

Community
  • 1
  • 1
Crab Bucket
  • 6,219
  • 8
  • 38
  • 73
  • I edited my question to remove confusion regarding the console app. That was just to explain what we do normally to use the assembly which exposes the API. The web app does not need to the console app, but does need to reference the assembly that exposes the API, and the assembly that exposes the API must stay in the same BIN directory with all the tons of other assemblies. ( I think the loading the native assemblies is the reason for that ) – Darrin Doherty Jun 24 '13 at 18:33
  • 1
    Thanks for that. I still think bin referencing would work. Or maybe then a pre-build step to the web app to copy the contents of the API into the bin folder of the web app. the lot would just have to come over if they are all interdependant. In web app you often have a third party folder where you put all external libraries and reference from there - as an alternative to puttin gthem direct in the bin. If you let us know why that won't work then we can all think up something else for you. Cheers – Crab Bucket Jun 24 '13 at 20:34