AppDomains and PrivateBinPath

  • Thread starter Thread starter RobinS
  • Start date Start date
R

RobinS

I have a license for a 3rd party component that has different versions for
debug and release, but the same name.

To automate the build and deployment, I put the debug version of the
license in a folder under the main project called \license_debug, and the
release version under \license_release.

I can handle which version is deployed with the build configuration. The
question is how to append the path programmatically so the application
looks in the application's folder, and then in the lower path.

In .Net 1.1, there was AppDomain.AppendPrivatePath, but this has been
deprecated, so I would rather not use it. It has been replaced with
PrivateBinPath.

All of the examples that I see involve multiple domains and add-ins, which
is way more complicated than my problem. This is what I'm trying now:

static void Main()
{
AppDomainSetup domainInfo = new AppDomainSetup();
#if DEBUG
domainInfo.PrivateBinPath = "license_debug"
#else
domainInfo.PrivateBinPath = "license_release"
#endif

AppDomain thisAD = AppDomain.CreateDomain("MyApp", null, domainInfo);
this.AD.Load("MyApp");

//single instance code
//splash screen stuff

Application.Run(new MainForm());

AppDomain.Unload(thisAD);
}

When I run the app, I get a license exception, so this is not working. Any
idea what I'm doing wrong?

Also, if I load the main assembly, do I have to load all of the other
assemblies into the AppDomain?

I haven't worked with AppDomains before, so any guidance you can provide in
this matter will be greatly appreciated.

Thanks,
Robin S.
 
Hi RobinS

You could always change your post build statements to copy the license file
to the same location, regardless of build type.
Personally, I would copy them to the same folder as the binaries, so the
components can find them without searching other folders. It simplifies
things, and there is no need for any #if DEBUG statements in the code.

Also, according to the documentation, PrivateBinPath :

"Gets or sets the list of directories under the application base directory
that are probed for private assemblies."

As you are not looking for private assemblies in that folder, I doubt the
application is even searching there for your license file. (But I may be
wrong! ;-D )

1. Does your 3rd party component have any properties to indicate where the
license file is stored?
2. Do you have to put it in a subfolder, underneath the binaries folder or
can you put it in the same folder as the executable ?

Ged
 
Thanks very much for responding. I really need to figure out how to fix
this, as I am currently manually renaming the files based on how I am
deploying the application which is just wrong wrong wrong and a pain in the
a**. Comments below.

Hi RobinS

You could always change your post build statements to copy the license
file to the same location, regardless of build type.
Click to expand...

We are using ClickOnce deployment, so we can't do post-deployment stuff.
But that's not what you said. You said "post build statements". I haven't
used post build statements in Visual Studio; how do I do that? I don't even
mind deploying both of the licenses in their respective folders, and then
have the build copy the right one up one level to the same folder as the
executable, if that would work and if ClickOnce would deploy it correctly
(50/50 chance, right?).
Personally, I would copy them to the same folder as the binaries, so the
components can find them without searching other folders. It simplifies
things, and there is no need for any #if DEBUG statements in the code.
Click to expand...

Ideally, the license could sit in the same folder as the binaries, the
problem is I have *two* licenses with the same name, and it needs to deploy
one when doing release build, and the other when doing the debug build. So
it seemed to me it would be easier to put them each in a separate
subfolder, and attach the appropriate folder to the path. That was my
theory anyway.
Also, according to the documentation, PrivateBinPath :

"Gets or sets the list of directories under the application base
directory that are probed for private assemblies."

As you are not looking for private assemblies in that folder, I doubt the
application is even searching there for your license file. (But I may be
wrong! ;-D )
Click to expand...

We used to have this working in .Net 1.1 with AppendPrivatePath, but they
have deprecated that, and even when I try it, it says it is obsolete and it
doesn't work, and you should use PrivateBinPath instead. (Sigh.) So I do
believe it will look for the license this way.

1. Does your 3rd party component have any properties to indicate where
the license file is stored?
Click to expand...

Of course not -- that would be too easy. And to add insult to injury, the
company was purchased by Microsoft last quarter. Their website says if
you've purchased a license, you can continue to use the product for life,
but there is no support.
2. Do you have to put it in a subfolder, underneath the binaries folder
or can you put it in the same folder as the executable ?
Click to expand...

I can put it in the same folder as the executable, but I have to have a way
to put the right version there.

The other thing I might be able to do is to include the license as an
embedded resource. So I wondered if I let the development one deploy in the
same folder as the application, but embedded the release one, could I only
include that when building in release mode or something like that?

Thanks again for responding. I'm open to any suggestions that will help me
fix this problem.

Robin S.
--------------------------------------
 
The Post-build event command line is part of the project properties.
In there, you can issue commands to execute once the build has finished.
I currently use it to copy some config files to a directory under my
release/debug folder.
You could try something like this - (just the bits between the quotes) :

(Release Build)
"copy /y $(ProjectDir)licence_release\*.* $(TargetDir)"

(Debug Build)
"copy /y $(ProjectDir)license_debug\*.* $(TargetDir)"

You can replace the *.* with the specific filename if you prefer.
Once the build is complete, the post-build event will copy the correct file
to the target directory (which will be either the release or debug folder,
depending on what build you are doing).
Then, your deployment will always have the correct license file without any
further interaction required.

HTH

Ged
 
Ged,

Thanks very much for your help. This is definitely going in the right
direction.

Is there a way to set different command lines for each build configuration?
The Configuration and Platform dropdowns at the top of the Build Events tab
in the properties is set to N/A and it is greyed out. Is there a different
place to set these command lines?

So what I'm trying now is to put two IF statements in there, and it seems
to work.

IF $(ConfigurationName) == Release copy /y ...
IF $(ConfigurationName) == Debug copy /y ...

Of course, I had to have a license file included as a default even though
it was going to be copied over, so that ClickOnce would recognize that it
had to deploy a file.

This resolved a problem I've been dealing with for a while, and I can't
tell you how much I appreciate your help.

Thx,
Robin S.
----------------------
 
Hi Robin S.

Just checking my build events tells me you don't have to set the post-build
command line for each build configuration.
If you use the macros $(ProjectDir), $(TargetDir) etc., to build up your
command line, they will automatically change based on the build type.

You can check this by clicking the Edit Post-build button, then clicking the
"Macros >>" button and looking at the macros (e.g. $(TargetDir), $(OutDir),
$(ConfigurationName) etc). They will change between Debug and Release,
depending on the build type selected in the main toolbar.

You don't need to have the IF $(ConfigurationName) == ... in your post build
command line.

I'm happy to have helped :-)

Ged
 
I do have to check the configuration name so I know which folder to copy
the license from. It's working great, and I'm very happy about it. Even
better, so is my team.

Thanks again.
Robin S.
------------------------------
 
Back
Top