1

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?

Improve this question
3
  • 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
    Commented Mar 8, 2012 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
    Commented Mar 8, 2012 at 19:15
  • What if i rename the solution to different name...so two solutions with different name and same web parts
    – Rajesh Kumar
    Commented Jun 15, 2017 at 14:14

2 Answers 2

Reset to default
0

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.

Improve this answer
0

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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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