Home/ Questions/Q 4340704
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-21T11:23:07+00:00

I have a pretty large system to deploy, plenty of components and built to

  • 0

I have a pretty large system to deploy, plenty of components and built to be quite extensible. There is a core set of components which are necessary for pretty much anything, and other sets of components which do more specialised things (to the point of each set being an application in their own right – this isn’t necessarily true now, but we’re headed that way…)

I would like to try and put some structure into things when I deploy. I was thinking along the lines of:

  • c:\program files \ MyCompany \ MyBigSystem \ App1
  • c:\program files \ MyCompany \ MyBigSystem \ App2
  • c:\program files \ MyCompany \ MyBigSystem \ App3
  • c:\program files \ MyCompany \ MyBigSystem \ AppN
  • c:\program files \ MyCompany \ MyBigSystem \ Core

The files in e.g. …\App1 will undoubtedly have dependent files in …\Core, but obviously I want to avoid redistributing these files to the …\App1 folder. I want App1 to pick them up from the Core folder.

I am struggling to see whether this is possible.

Here’s some constraints and observations:

Currently, every component is built using static references. I am more likely to deploy everything into a single folder than to abandon this stance. Furthermore I don’t want to modify any program code which assumes this deployment structure. So wholesale changes such as using Assembly.LoadFrom, or smartly setting the appDomain’s path, are out.

I am however amenable to app.config entries, because these can be written during setup.

I have looked at (and very briefly tested) <probing>, which at first glance appeared ideal, but ended up being unsuitable because of its constraint of being a subdirectory

I have looked at <codeBase> – I didn’t read into this fully because having to register a dozen or so core assemblies individually put me right off (although having said that, it looks like it could well get me what I want if I were prepared to take the trouble).

Can anyone suggest any other approach I might consider?

TIA, Pete

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    In the end I got almost what I wanted but not quite. I ended up with all the folder structure that I wanted….

    • c:\program files \ MyCompany \ MyBigSystem \ App1
    • c:\program files \ MyCompany \ MyBigSystem \ App2
    • c:\program files \ MyCompany \ MyBigSystem \ App3
    • c:\program files \ MyCompany \ MyBigSystem \ AppN
    • c:\program files \ MyCompany \ MyBigSystem \ Core

    ….but had to put the main executables in the “MyBigSystem” folder, i.e.

    • c:\program files \ MyCompany \ MyBigSystem \ App1.exe
    • c:\program files \ MyCompany \ MyBigSystem \ App1.exe.config
    • c:\program files \ MyCompany \ MyBigSystem \ App2.exe
    • c:\program files \ MyCompany \ MyBigSystem \ App2.exe.config

    I supplemented this structure with <probing> entries in the executables’ config files, e.g.

      <runtime>
    <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
      <probing privatePath="Core"/>
    </assemblyBinding>
  </runtime>

    This seemed to keep the root folder as uncluttered as I could reasonably hope for. It also allows App6 to access dependent libraries in App1, for example, should this ever be necessary. (It was for this reason that I shied away from the GAC – if ever we get Apps dependent on apps, I can see us having to GAC everything, which would be inappropriate.)

    No code changes in this approach other than in the configs. The main challenge became getting the VS Setup project to put everything except the .exe and the .exe.config in the subfolder.

    • 0