1
Vote

Deployment to GAC

description

It appears that GEL has some bazaar dependencies that prohibit its use when deployed to the GAC.
 
These include:
EnvDTE 7.0.3300.0
Microsoft.Data.ConnectionUI.Dialog 8.0.0.0
 
But can we qualify these dependencies are really needed?
 
Of course one workaround is to deploy these dependencies to the GAC when installing GEL.
 
Other is to avoid deploying to GAC and only deploy to PublicAssemblies folder, which probably makes sense considering its use for recipes.
 
If that is the case, a notice should be loud and clear about where it can and should be installed.

comments

ctavares wrote Mar 29, 2007 at 6:30 PM

These dependencies are indeed required. EnvDTE in particular is used just about everywhere in the code. Putting it in PublicAssemblies is really the best place for it. I'll see about adding a note to the release.

jezzsa wrote May 7, 2007 at 7:13 AM

Thanks Chris, understood EnvDTE is required. but check the version. the version required here is 7.0.3300. Shouldn't this be a more recent version? Like the version for VS2005 (EnvDTE 8.0.0.0)?

I'll give you a usage sceanrio.I have a DSL I want to use the 'ClassBrowserEditor' from this library as the UITypeEditor on a domain property. Since DSL assemblies are deplyed to the GAC, I would have to deploy RecipeFramework.Extensions.dll also to the GAC.But it wont load from the GAC with these bazaar dependencies.

jezzsa wrote May 7, 2007 at 7:50 AM

Just another comment, from an issue I am also running into.

If the PublicAssemblies folder is the recommended place to install this assembly, then multiple versions of it are not possible (i.e. DLL Hell).

I notice that the 'Service Factory' installs this assembly to the PublicAssemblies folder (version 1.0).Now if I want to use a different version say (1.3) in my factory, the last factory installed wins - right? (-> dll hell)You cant assume only one factory is installed per machine.

If you really want people to use this assembly in their factories, GAC deployment, can be the only option really.You cant assume it will only be used in GAT packages. Factories of today use DSL's, and therefore need to load these types from GAC.

jezzsa wrote May 7, 2007 at 9:14 AM

I guess in retrospect. that the real issue here is what was this library designed for?

If soley for use from GAT packages then, then it should only be deployed privately in same folder as GAT package using it. (This will avoid multiple copies and DLL hell in PublicAssemblies folder.)

If it intended for use by factories in general (which is it useful for), then I think its needs to be split into: functionality that is specific to GAT packages, and functionality that can be used from DSL's too (like the UI editors, DTE helpers etc). The shared functionality for use by DSL needs to be deployable to GAC, since all DSL's have to be deployed to GAC.

There is no good workaround at present since just deploying it to PublicAssemblies folder will cause DLL hell for all factories doing this (multiple versions of GEL in same physical directory). Following GAX's assumptions here on this is not safe, you will only ever have one version of GAX installed on the machine, and therefore installing GAX assemblies to PublicAssemblies cache is OK. That is a not a safe assumption for GEL.

Service Factory has already proven this mistake. But this is expected since service factory is first factory to use DSL's and share functionality from GEL. Perhaps its time to review?

wrote Feb 13, 2013 at 7:33 PM