Microsoft 开发人员网络 > 论坛主页 > SharePoint - Development and Programming > Adding Referenced Assemblies to WSP (VSeWSS)
提出问题提出问题
 

问题Adding Referenced Assemblies to WSP (VSeWSS)

  • 2008年7月30日 13:40u4jef 用户奖牌用户奖牌用户奖牌用户奖牌用户奖牌
     
    I spent a couple of days looking for a way to include my Web Part's referenced assemblies in the WSP that gets generated by VSeWSS 1.1 before stumbling on this:

    1.  Add the referenced assembly (say, utilLib.dll) to the Web Part project in Visual Studio (I added it in the same folder as myPart.webpart etc...)
    2. Edit manifest.xml to include the entry <Assembly Location="utlLib.dll" DeploymentTarget="GlobalAssemblyCache" /> under <Assemblies>
    3. Hit Deploy in Visual Studio
    4. Find that utilLib has been packaged and will be deployed along with the Web Part assembly

    I found that this only worked if the assembly was added to the Visual Studio project, not just placed on the filesystem and I now have a post-build event that overwrites the assembly with the latest version on each build.

    So, does anyone have an opinion on this approach?
    Is this the best way to package referenced assemblies without replacing the VSeWSS deploy process?

全部回复

  • 2008年7月30日 14:58Eric Kraus [MSFT] 用户奖牌用户奖牌用户奖牌用户奖牌用户奖牌
     
    The reason is because the .ddf file is what actually controls what gets included in the WSP.  If using VSeWSS, this may be your only option as the .ddf is generated for you. 

    Otherwise, in development using "from scratch" VS projects, you would have to edit your .ddf manually and add the physical location where to find the DLL.  Rather than dealing with install locations, I typically add the assembly as a reference to my project and tell it to Copy Local = True.  Then I can reference the relative "bin" folder to get all of the assemblies I need.  (this being done automatically for you with VSeWSS).

    I would suggest your method is a good approach.

    ----------
    Eric Kraus - MSFT
    http://blogs.msdn.com/ekraus
  • 2008年8月14日 16:06David R. Henderson 用户奖牌用户奖牌用户奖牌用户奖牌用户奖牌
     
    I'm facing a similar problem.  My webpart loads a utility assembly, so both assemblies need to be deployed as part of a single SharePoint feature.  I have a VS solution that contains two projects-- one is my webpart assembly, the other is my utility assembly.  The webpart project includes a reference to the other project and I added an Assembly element in the manifest.xml file.  (I am using the VS 2008 Extentions for WSS 3.0)  The problem is that the utility assembly isn't getting included in the WSP file, so it isn't available during the deploy.

    Is adding the assembly to the project in Visual Studio really the correct approach?  Something about that seems wrong to me.  It seems to me that the VSeWSS tools should provide a cleaner way of specifying that the utility assembly needs to be included in the WSP file.
  • 2008年8月14日 18:59Dan Keeling 用户奖牌用户奖牌用户奖牌用户奖牌用户奖牌
     
    This is one of a couple large drawbacks to using the VSeWSS.  With the need for external DLL's you can also just create a project and add a CAB project to it, since DLLs going either to the BIN folder or the GAC do not need to be nested, a simple manifest file with Assemblies and SafeControl entries, and the DLL's can be thrown into a cab with a setup project.  You can also include it in your main project to be built, and then install both WSP's? 


    -DK http://dkeeling.spaces.live.com
  • 2008年8月14日 19:39Michael Van Cleave 用户奖牌用户奖牌用户奖牌用户奖牌用户奖牌
     
    All,
         I have run in to the same situation and ended up converting my projects to use the WSPBuilder add-in that you can find on CodePlex.  It is much easier to use and you have a lot more control over the packaging.

    Give it a try and let me know what you think.

    HTH.

    Michael
    Michael Van Cleave - MCT, MCTS, MCSD .NET and SharePoint Consultant - Qortex LLC.
  • 2009年2月16日 22:12PixieTech 用户奖牌用户奖牌用户奖牌用户奖牌用户奖牌
     
    Adding the dll,
    at the moment there is no way with VSeWSS to add another dll to the WSP when you are building a web part. I've seen many examples of post build events etc. I think that wsp builder offers a much better solution as it allows you to specify what goes into your wsp but this product is not supported by Microsoft per say. Adding the dll to your project is not advised especially if the dll is from another project that you are controlling. If it is a dll that you will never change then there shouldnt be an issue. This is a question of taste.

    If you have your heart set on on only using VSeWSS then the easiest way is to add the required dlls to the project.
  • 2009年7月3日 18:12jendxb 用户奖牌用户奖牌用户奖牌用户奖牌用户奖牌
     
    PixieTech,

    VSeWSS 1.3 March CTP supports adding/referencing additional assemblies. E.g. this is used to deploy workflows for instance. I haven't used this for any webpart work yet, but would think that it works fine too, as all this reference (along with the CopyToLocal setting) does is create the respective entry in the manifest.

    jennifer - www.finalcandidate.com
  • 2009年8月25日 11:01Sandeep Nakarmi 用户奖牌用户奖牌用户奖牌用户奖牌用户奖牌
     
    Hi,

    I was having the same issue where the referenced dlls in a webpart were not included in the WSP and when i deployed the project, it just failed to deploy saying that the referenced dll was not found. When i looked inside WSP, it was not there either.

    So i upgraded to VseWSS 1.3 March CTP and checked the project. Now the manifest file contains the entries for referenced assemblies and
    WSP contains assemblies itself. The solution deployed fine along with referenced assemblies. At last !!!!


    sandeep nakarmi http://sandeepnakarmi.wordpress.com
  • 2009年9月27日 2:45Xiaofeng WangMVP用户奖牌用户奖牌用户奖牌用户奖牌用户奖牌
     
    I'm not sure VSeWSS 1.1. At first, I still have the same problem with 1.3 March 09 CTP. 

    But when I set the reference to CopyLocal=true,  the mainifest.xml finally include it.  

    Hope this helpful.

    Xiaofeng Wang | http://www.leoworks.net | Beijing P.R.C
  • 2009年9月27日 14:41Pablo Gazmuri 用户奖牌用户奖牌用户奖牌用户奖牌用户奖牌
     
    Xiaofeng is correct, CopyLocal=true ensures that the dll will be copied into the build directory, which is helpful.

    Also, your initial approach was fine as well... copying the dll in a post build event is also fine.

    But I'd just like to echo Michael's suggestion that WSPBulder from codeplex be used to build these types of solutions.  It frees you from having to edit the manifest.xml directly, and is in general simpler and (IMHO) more straightforward to use.

    If any of you haven't tried WSPBuilder, please give it a try!