Hello,

I'm integrating some code with Visual Studio. All my code is managed, and I
make use of registration attributes and regpkg.exe to reflect over the
assembly to generate registration information. This registration information
gets places into the registry and VS goes through well known registry keys
and uses COM interop to load our packages as appropriate.

I would like some of these managed packages to make use of services from
other custom assemblies. I could place these other assemblies in the GAC,
but I'd like to avoid that. Modifying the machine configuration file
similarly seems like a bad idea. As I don't own the executable (devenv.exe)
I cannot use an application configuration file. The only option then seems
to be to use System.Reflection.Assembly.LoadFrom and specify a path, such as
a path relative to the executing assembly (e.g. the one that got loaded by VS
using COM interop).

Are there other options or best practices to follow? Is there a way to
provide hint paths or otherwise participate in assembly probing in such a
scenario, without providing a fully qualified path?

Although this question is specific to VS, the same question applies to other
products where an assembly writer does not own the executable (such as an MS
office addin scenario); if there is a means of loading a managed assembly
into the process of another executable then how can this managed assembly
make use of other assemblies as described above?

Thank you,

Notre

Put the DLL into the bin folder?

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
A watched clock never boils.

"Notre Poubelle" <(E-Mail Removed)> wrote in message
news:16C6D798-3914-4276-8CF8-(E-Mail Removed)...
> Hello,
>
> I'm integrating some code with Visual Studio. All my code is managed, and
> I
> make use of registration attributes and regpkg.exe to reflect over the
> assembly to generate registration information. This registration
> information
> gets places into the registry and VS goes through well known registry keys
> and uses COM interop to load our packages as appropriate.
>
> I would like some of these managed packages to make use of services from
> other custom assemblies. I could place these other assemblies in the GAC,
> but I'd like to avoid that. Modifying the machine configuration file
> similarly seems like a bad idea. As I don't own the executable
> (devenv.exe)
> I cannot use an application configuration file. The only option then
> seems
> to be to use System.Reflection.Assembly.LoadFrom and specify a path, such
> as
> a path relative to the executing assembly (e.g. the one that got loaded by
> VS
> using COM interop).
>
> Are there other options or best practices to follow? Is there a way to
> provide hint paths or otherwise participate in assembly probing in such a
> scenario, without providing a fully qualified path?
>
> Although this question is specific to VS, the same question applies to
> other
> products where an assembly writer does not own the executable (such as an
> MS
> office addin scenario); if there is a means of loading a managed assembly
> into the process of another executable then how can this managed assembly
> make use of other assemblies as described above?
>
> Thank you,
>
> Notre

Thank you for your relpy Kevin. Which bin directory are you referring to?

Hi

I think Kevin means the bin folder of your EXE app.
In .NET, an exe loaded, it will trying to probe in GAC or currect dir(also
the path defined in the app.config).
If you do not want to put in the GAC, I think it should be a private
deployment, we can put it in the bin folder. Or use the
<probing> Element
Runtime Settings Schema | Configuration File Schema | Specifying an
Assembly's Location | How the Runtime Locates Assemblies
Specifies application base subdirectories for the common language runtime
to search when loading assemblies.



Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.

The <probing> configuration element will only work inder the application
root folder.

However, and this is not advisable, you *can* load an assembly from outside
the application path using System.Reflection.Assembly.LoadFrom() method.
There are reasons why this is not advisable, and I would advise reading up
on this method prior to using it.:

http://msdn.microsoft.com/library/de...dfromtopic.asp

--
HTH,

Kevin Spencer
Microsoft MVP
..Net Developer
A watched clock never boils.

""Peter Huang" [MSFT]" <v-(E-Mail Removed)> wrote in message
news:(E-Mail Removed)...
> Hi
>
> I think Kevin means the bin folder of your EXE app.
> In .NET, an exe loaded, it will trying to probe in GAC or currect dir(also
> the path defined in the app.config).
> If you do not want to put in the GAC, I think it should be a private
> deployment, we can put it in the bin folder. Or use the
> <probing> Element
> Runtime Settings Schema | Configuration File Schema | Specifying an
> Assembly's Location | How the Runtime Locates Assemblies
> Specifies application base subdirectories for the common language runtime
> to search when loading assemblies.
>
>
>
> Best regards,
>
> Peter Huang
> Microsoft Online Partner Support
>
> Get Secure! - www.microsoft.com/security
> This posting is provided "AS IS" with no warranties, and confers no
> rights.
>

Hi Peter,

Thanks for this. This is what I guessed Kevin meant. I'd like to avoid
placing my assemblies underneath the EXE app, since I don't own the EXE. In
the worst case scenario, I might consider placing them in a common subfolder
folder of the third party EXE. For example, if the EXE exists in:

Program Files\Microsoft Visual Studio 8\Common7\IDE\

Then I might place them in

Program Files\Microsoft Visual Studio 8\Common7\IDE\<MyCompanyName>
or
Program Files\Microsoft Visual Studio
8\Common7\IDE\<MyCompanyName>\<Assembly1 Name>
Program Files\Microsoft Visual Studio
8\Common7\IDE\<MyCompanyName>\<Assembly2 Name>

From what I've read about probing, by default the runtime does not look for
assemblies in any arbitrary subfolders of the EXE's folder, unless I create
a <probing> configuration element. But this probing configuration element
must be associated with a configuration file, which is one of the application
EXE (which I don't own) or the machine configuration file (which I don't want
to change).

Notre

Hi Kevin,

Thanks for the further information on the <probing> configuration element.
As I mentioned in my reply to Peter's post, I'm still reluctant to be
constrained to putting my assembly beneath an exe which I don't own.

I was looking at the System.Reflection.Assembly.LoadFrom() method as the
only alternative. I did read through some of the documentation you referred
to, but I'm not sure I appreciate the drawbacks of this approach. Is the
main concern related to security - potentially getting the wrong assembly or
loading an assembly that has malicious intent?

Thanks for your help!
Notre

Hi

If you do not want the put the DLL into GAC, I think you need to use the
LoadFrom approach.
Because the CLR will try to load the assembly from GAC or bin(including the
probing setting), if you do not want them, I think you need to use the
LoadFrom to explicitly load the assembly yourself but not the CLR.

Best regards,

Peter Huang
Microsoft Online Partner Support

Get Secure! - www.microsoft.com/security
This posting is provided "AS IS" with no warranties, and confers no rights.