This project is read-only.

assembly in wsp

Aug 13, 2009 at 2:40 PM
Edited Aug 13, 2009 at 2:41 PM

You say in your docs "It is important that the assembly isn’t included and deployed through other Web Solution Packages because this potentially can cause conflicts."

Why is that? I would have thought that it would only be bad if a developer had a reference in a project to an older version of your dll .... such that if an admin had installed a newer version of your dll, then the developer's wsp would overwrite your newer dll with an older one that he was referencing.... Or is there some other reason?


Aug 13, 2009 at 4:12 PM

Hi larbster,

There is another reason as well. I think the easiest way to explain the problem is by example. Let’s say we have Solution Package A, and Solution Package B. Both Solution Packages contains the same version of Assembly X, and both Solution Packages contains some other assemblies that make use of Assembly X.

First Solution Package A is deployed, which means Assembly X is deployed to the servers on the Farm. Next Solution Package B is deployed. During this deployment Assembly X from Solution Package A will be overwritten with the version of Assembly X located in Solution Package B. - This is the scenario you describe, and you’re right. Sometimes this wouldn't be an issue (however in some cases it will).

However it first gets really problematic when you start retracting solution packages from your Farm. Let’s say that you don't need Solution Package B any longer, and you decide to retract it from the farm. This means that Assembly X will be retracted as well, this will result in a missing reference in the assemblies located in Solution Package A that was dependent on Assembly X.

I hope this answers your question.

Peter Brinch Larsen