|
The new support for solution deployment in WSS 3.0 is great, HOWEVER if you are deploying shared assemblies into the GAC you should be aware of the fact that WSS installs these assemblies WITHOUT trace references.
Below is a quote from Junfeng Zhang's blog.
"When you install an assembly to GAC, you have the option to specify an Assembly Trace Reference.
And we strongly recommend that you specify a trace reference, for the reason I will discuss below.
The idea behind trace reference is really simple. When multiple applications install the same assembly, and one application is uninstalled (thus uninstall the assembly it carries), other applications won't be broken."
Published Monday, September 13, 2004 12:38 AM by junfeng
|
Web Parts from Bamboo will be deployed into "bin" with custom policies, but we also put shared assemblies into the GAC just because they are shared and needs to be reference counted. We can't put them into the bin since retracting one of the solutions will break everything that is referencing the shared assembly.
Another reason for putting assemblies into the GAC is that some code MUST run with full trust so we put our gateway assemblies in the GAC too.
An example of this is if you have code that needs to use System.DirectoryServices. Your gateway assembly will demand the proper DirectoryServicesPermission permission and then assert FullTrust. We will post a detailed walk through on how to create these gatways with custom permission classes.
So if you decide to put anything into the GAC make sure it's NOT shared by anyone else since then it will break if you retract one of the solutions....
<Assembly Location="xxxxx.dll" DeploymentTarget="GlobalAssemblyCache" />
By using Reflector and looking at the FusionInstall class you can see that the assembly is added without a trace reference.
I hope that MS will change this in an upcoming service pack since it really makes sharing assemblies even harder than it already is...
Some people suggest that we should have two solutions, one for the shared assemblies and one for the Web Part. The problem with this approach is that it doesn't help at all. The problem is that as more ISVs target SharePoint we will depend on the same assemblies. Retracting solution A from company B will break all solutions that share assemblies with solution A.
If anyone out there has a workaround for this "problem" please share it, we are trying to find a solution to this and if we come up with a viable solution we will share it here.
WSP solutions are great for inhouse deployments but because of the lack of trace references it fails miserably when used by commercial SharePoint vendors like Bamboo Solutions.
/Jonas
|
Posted
Jun 23 2008, 04:19 PM
by
Jonas Nilsson
Please sign into Bamboo Nation to leave a comment.