Take the 2-minute tour ×
SharePoint Stack Exchange is a question and answer site for SharePoint enthusiasts. It's 100% free, no registration required.

Im working on a newer version (2.0) of my sharepoint2010 wsp (which contains several features and webparts). I have dev+test servers which have a webapp each with v1.0 of wsp. In the newer version there are several updates to the existing webparts. I want to deploy it to my dev/test new webapp so that I have both webapps working with their own versions (ie both 1.0 and 2.0) until 2.0 is released. I have a couple of options:

1) change all the AssemblyVersion/AssemblyFileVersion to 2.0 of every feature,package,assmebly; Add a assemblyredirect in web.config only for the v2.0 webap. (There are about 60 references i have to change from 1.0.0.0 to 2.0.0.0)

2) deploy the v2.0 to bin instead of gac (this didnt work as i get security exceptions - cannot allowpartiallytrusted callers). My v1.0 is in gac.

Questions: 1) Is there any other recommended way? 2) Is #1 the only solution or 3) Is there a easy way to make #2 work?

share|improve this question
    
When deploying to bin, is your solution referencing any custom assemblies in GAC. If yes, then your assembly in GAC should have [assembly: AllowPartiallyTrustedCallers()] in assemblyinfo.cs file for that assembly. –  sssreddy Mar 8 '12 at 17:03
    
yes, but they are third party assemblies (captcha.dll etc). I cannot modify those assemblies. But all assemblies from my solution are within the _vti_bin. –  vasya10 Mar 8 '12 at 19:15
add comment

2 Answers

up vote 0 down vote accepted

If side-by-side is a requirement, then you cannot use the assembly redirects. Those are designed to run new version when the old is requested. Additionally, side-by-side in SharePoint is very difficult - I would not even try it.

If you absolutely need to keep old version is some places, then you should create new solution / features and deploy them as needed. At the appropriate time, retract the old stuff.

share|improve this answer
add comment

I would advise against running multiple versions of the same WSP in a single farm. Although a solution can have a specified scope (e.g. web application/site etc.) parts of a WSP (namely globally deployed assemblies, files deployed to the 14 Hive) are deployed farm wide.

You may be able to get it working, but what happens when you find a bug in v2? You will spend another X amount of time confirming if it is due to sharing a farm, or if it is actually a bug.

The solution store does not use a concept of multiple versions of a solution, and assumes one is installed. You would have to name them differently too. This would make for maintenance hell.

If you need to compare multiple versions (say a dev branch and a prod branch), in the past I have had multiple single server farms (integration environments) (VMs pattern stamped) with the specified versions. This is the simplest way in my mind to do this, and will make deployment/promotion easier too.

share|improve this answer
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.