Sunday, 22 July 2007

Building and deploying SharePoint Solution packages

Following a comment left elsewhere on this blog, I thought I'd cover exactly what SharePoint Solution packages are, including how they are built and deployed to other SharePoint environments.

First of all, let's be clear on exactly what a Solution package is. Note I'm using 'Solution' with a capital S  in this article to distinguish between what we are discussing here and the general idea of a technical solution built using SharePoint. A Solution is a package of SharePoint items for deployment - in physical terms it is a cabinet file (.cab) which is given the extension of .wsp to differentiate it from standard .cab files. Other articles on this blog cover the idea of using SharePoint Features to deploy functionality, so let's also be clear on the relationship between Features and Solutions. In general terms, some of the tasks which cannot be done with a Feature alone but can be done with a Solution include:

  • Deployment of certain files to the filesystem, e.g. an assembly for workflow or web parts, custom files which will reside in the ‘12’ folder 
  • Deployment of web part definition files (.webpart)
  • Web.config modifications e.g. the ‘SafeControls’ entry required for a custom web part
  • Code Access Security config modifications e.g. those required for custom web parts not running from the GAC

In addition to being able to do these things, Solutions can also contain Features. The way I think of it is that the Solution wraps the Feature. In actual fact, I always recommend that even if they don't need to be (e.g. we're not doing anything in the list above), Features are always deployed as part of a Solution.  The reason for this is that the Solution framework takes care of deploying all required files to all Web Front End (WFE) servers in a SharePoint farm. This alone is incredibly useful in working towards repeatable deployments, and ensures your WFEs stay synchronized.

How Solutions are specified

The key file used to specify what a Solution package consists of is the manifest.xml file. Going back to my earlier post on deploying web parts, the manifest.xml file for that scenario looks like this:

<Solution xmlns="http://schemas.microsoft.com/sharepoint/" SolutionId="122C0F04-78B7-4d42-9378-6F8B4F93ADD1">

  <FeatureManifests>

    <!-- note this is the location in the cab file! -->

    <FeatureManifest Location="COB.Demo.WebPartDeployment.WriteToFileWebPart\feature.xml" />

  </FeatureManifests>

  <Assemblies>

    <Assembly     Location="COB.Demo.WebPartDeployment.WriteToFileWebPart\COB.Demo.WebPartDeployment.WriteToFileWebPart.dll"

        DeploymentTarget="GlobalAssemblyCache">

      <SafeControls>

        <SafeControl Assembly="COB.Demo.WebPartDeployment.WriteToFileWebPart, COB.Demo.WebPartDeployment, Version=1.0.0.0, Culture=neutral, PublicKeyToken=9f4da00116c38ec5"

                    Namespace="COB.Demo.WebPartDeployment"

                    Safe="True"

                    TypeName="*" />

        </SafeControls>

    </Assembly>

  </Assemblies>

  <DwpFiles>

    <DwpFile

     Location="COB.Demo.WebPartDeployment.WriteToFileWebPart\COB.Demo.WebPartDeployment.WriteToFileWebPart.webpart"

      FileName="COB.Demo.WebPartDeployment.WriteToFileWebPart.webpart" />

  </DwpFiles>

</Solution>


This is assuming the web part is being deployed to the GAC - for this illustration this is a simpler scenario than deploying to the web application's bin directory, where Code Access Security (CAS) policy would also be required. Effectively, the manifest specifies that the Solution package consists of the following:

  • a Feature with a header file named 'feature.xml'
  • an assembly for deployment to the GAC named 'COB.Demo.WebPartDeployment.WriteToFileWebPart.dll'
  • an entry in the SafeControls section of the application's web.config file, specifying all types in the specified assembly should be treated as safe
  • a web part definition file named 'COB.Demo.WebPartDeployment.WriteToFileWebPart.webpart' - this will be deployed to the web part gallery on the site

Importantly, all these details in the manifest.xml file are only used by SharePoint when the generated Solution package is deployed. They are effectively the instructions which say "go and get this item from the .wsp file and put it here". The actual process for generating the .wsp file is another task.


Building Solution packages

There are 2 options for building the actual package - build it manually using makecab.exe, or use an automated solution - there are several community-developed tools/techniques available. Since it's always good practise to understand what's actually happening in such processes, we'll cover how to do it manually here.

The first step is to write a .ddf (Diamond Directive File). This is a set of instructions for makecab.exe on how to build the folder hierarchy inside the .cab file. For my web part example, my file looks like:

.OPTION Explicit

.Set CabinetNameTemplate="COB.Demo.WebPartDeployment.WriteToFileWebPart.wsp" 

.Set DiskDirectory1="Package"

;***

 

manifest.xml

 

;** this directory name is used for the folder name under 12\TEMPLATE\Features, so should

;** match up with what you want to call the feature!

.Set DestinationDir=COB.Demo.WebPartDeployment.WriteToFileWebPart

elements.xml

feature.xml

 

.Set DestinationDir=COB.Demo.WebPartDeployment.WriteToFileWebPart

WebPart\COB.Demo.WebPartDeployment.WriteToFileWebPart.webpart

WebPart\COB.Demo.WebPartDeployment.WriteToFileWebPart.dll

 

;***


This file tells makecab.exe to do the following:

  • create a .cab file named 'COB.Demo.WebPartDeployment.WriteToFileWebPart.wsp'
  • put the 'manfest.xml' file at the root of the hierarchy
  • put the 'elements.xml' and 'feature.xml' files in a subfolder called 'COB.Demo.WebPartDeployment.WriteToFileWebPart'
  • also put the 2 other files (with extensions .webpart and .dll) in this same subfolder, but that makecab.exe should look for these files in a subfolder on the main filesystem called 'WebPart'

This instructions file is then passed to makecab.exe with the following command-line command:

D:\SolutionDeployment\Development\COB.Demo.WebPartDeployment>"C:\Program Files\Microsoft Cabinet SDK\BIN\MAKECAB.EXE" /f COB.Demo.WebPartDeployment.ddf


Couple of things to note here. At the command prompt we have ensured the current directory is the directory where all our Solution files are kept. This ensures that our relative references in the .ddf file above can be resolved. We pass the /f parameter to indicate we are passing a directives file, and also pass the location of this file.

Assuming all the files/references are OK, this results in a .cab file with a .wsp extension which will be created in a subfolder under the current directory called 'Package' (the folder will be created for you if it doesn't exist). We now have a Solution package which can be deployed to another SharePoint server. But first let's take a peek inside - this can be done by temporarily renaming the extension to .cab. You should then see something like:



Deploying the Solution to other SharePoint servers

The final part is to actually deploy the Solution. First the .wsp file must be copied to the target server, and then we will use STSADM (SharePoint's command-line admin tool) to actually deploy the Solution. The following are the commands which used to perform the deployment:

stsadm -o addsolution -filename COB.Demo.WebPartDeployment.WriteToFileWebPart.wsp

stsadm -o deploysolution -name COB.Demo.WebPartDeployment.WriteToFileWebPart.wsp
   -url http://myWebApplication -immediate -allowGacDeployment -allowCasPolicies -force


The first command simply adds the Solution package to SharePoint's Solution store in the config database, and the second one actually performs the deployment of the package to the specified web application. These areas are fairly well covered in the SDK at http://msdn2.microsoft.com/en-us/library/aa544500.aspx.

Rather than write these commands at the command-line each time you wish to deploy the package, chances are over time you'll package these commands up into STSADM scripts which do the work. As an example, the script I use for the webparts example looks like:

:begin

@echo off

 

set solutionName=COB.Demo.WebPartDeployment.WriteToFileWebPart

set url=http://myWebApplication

set featureName=COB.Demo.WebPartDeployment.WriteToFileWebPart

@set PATH=C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN;%PATH%

 

echo --- Attempting to deactivate/retract existing solution...

 

stsadm -o deactivatefeature -name %featureName% -url %url% -force

stsadm -o retractsolution -name %solutionName%.wsp -url %url% -immediate

stsadm -o execadmsvcjobs

stsadm -o deletesolution -name %solutionName%.wsp -override

rem stsadm -o execadmsvcjobs

 

echo --- Adding solution %solutionName% to solution store...

 

stsadm -o addsolution -filename %solutionName%.wsp

 

if errorlevel == 0 goto :deploySolution

 

echo ### Error adding solution %solutionName%

echo .

goto end

 

:deploySolution

echo --- Deploying solution %solutionName%...

 

stsadm -o deploysolution -name %solutionName%.wsp -url %url% -immediate -allowGacDeployment -allowCasPolicies -force

stsadm -o execadmsvcjobs

 

if errorlevel == 0 goto :activateFeature

 

echo ### Error deploying solution %solutionName%

echo .

goto end

 

:activateFeature

 

echo --- Activating features in solution %solutionName%...

 

stsadm -o activatefeature -name %featureName% -url %url% -force

 

if errorlevel == 0 goto :success

 

echo ### Error activating feature %featureName%

echo .

goto end

 

:success

echo Successfully deployed solution and activated feature(s)..

echo .

goto end

 

:end

pause


Following the script through, this basically does the work of safely upgrading the Solution (in case it has been deployed previously), and also activating the Feature within the Solution.


Automating Solution builds

Earlier, we mentioned the idea of automating the process of building and deploying Solutions. There are several community tools/ideas in this area, a couple of the ones I'm aware of are:

Both of these effectively use Visual Studio post-build events to automate the build of the .wsp package.

Additionally, Microsoft's Visual Studio Extensions for Windows SharePoint Services effectively performs the same tasks. Although there is some inflexibility in the current version, this add-on for VS means that the whole process is automated by hitting the F5 button. I'd recommend taking a look if you're not aware of this. My post on creating lists with VSeWSS gives an overview of using it for that specific scenario.

41 comments:

Brian T said...

Morning Chris

Nice post this one chris makes the process very clear.

anand said...

Hi Chris,

I am facing few problem.

1. I am having feature one in which I am using ReceiverAssembly (with strong name).

2. The service provider company who is hosting sharepoint farm is not allowing any deployment of code in GAC. Every assembly should be loaded from bin folder of web application.

3.I tried using custom CAS policy in manifest file. (I am not sure what should be exact policy elements).

4. when I try to deploy solution, I am getting following error

Feature 'aaec2e08-1ccf-4712-ae5e-a33bea53a325' could not be installed because the loading of event receiver assembly

it is mandatory to put ReceiverAssembly in GAC.

Thanks,

Anand

Chris O'Brien said...

Hi Anand,

Yes, I haven't had chance to test but am 99% sure the Feature receiver assembly needs to be in the GAC.

HTH,

Chris.

Kate said...

Chris - Please Help! I've been banging my head on this for close to a week. So I downloaded this web part
(http://weblogs.asp.net/paulballard/archive/2007/05/01/sharepoint-moss-2007-forms-based-authentication-login-registration-web-part.aspx)
and used the setup.bat file supplied with it to install it, and it works. However, I needed to add some custom fields to the registration page, and so i changed the code appropriately but cannot seem to get it to update. I can't figure out how to deploy it. Can you explain the file hierarchy included? I can't figure out what is what. I want to update the wsp file, but can't get it to update and don't quite understand the manifests since i need to account for both login code and captcha code. I'm so frustrated! Can you help me?! :) Thanks!

Chris O'Brien said...

Kate,

You'll need to rebuild the Solution package (.wsp) with the updated files and reploy the Solution using STSADM -o upgradesolution.

To do this, you'll either need the original .ddf file or to recreate it, which will be slightly more difficult. Did the web part author supply it in the zip file?

Assuming you have the .ddf file, you should then rebuild the Solution as per the process in the 2nd part of this article.

HTH,

Chris.

Kate said...

Chris - thanks for the reply! No, there is no ddf file included in the zip file :( I tried to build one from an article I read online, and I was able to do it successfully however it still didn't update :-/ I guess my question is - are the webparts directly referencing the .cs files? I change the .cs code, but when I build the ddf I think it is building off the .webpart files and the .xml files... right? Are you able to look at the files breakdown in the zip? if not, I could describe the breakdown - there are just so many files that i'm not sure everything is getting updated correctly and I don't quite understand the relationships between them all. Thanks a ton!

Kate said...

sorry - another question - when I try updatesolution it says "Missing operation name or the operation name is invalid"

Chris O'Brien said...

Kate,

Managed to take a look. What I think you need to do is the following:

- make your code changes in the .cs files
- recompile the assembly - you'll need to use your own strong key to sign the assembly since the author hasn't supplied the original one
- change any references to the assembly in any of the files (e.g. manifest.xml) to reflect the new public key token (and version number if you incremented it)
- rebuild the .wsp file using makecab.exe and your .ddf file. The thing to ensure is that the resulting .wsp file has the same structure as the original one - compare by renaming both to .cab and examining the contents. Pay particular attention to the 'path' for each file.
- upgrade the solution using STSADM -o upgradesolution. Note it's upgradesolution not updatesolution as per your other comment!

Assuming their are no errors, you should check the updated assembly was deployed to the GAC OK - incrementing the version number may help here, otherwise just delete the assembly before running the upgradesolution command.

Essentially the task is about rebuilding the .wsp package in the same format with the updated files, and then running upgradesolution.

Best of luck,

Chris.

Kate said...

Chris, you've been an amazing help so far. I've done everything as described, made the wsp with the same structure as the old, rebuilt everything, changed the keys, versions, but everytime i call upgrade, even after deleting the assembly before hand, it still re-appears as the old version and key. And when I try to run the included uninstall from setup.bat, it gives me errors. How would you recommend getting rid of the old version and starting anew with my code?

Chris O'Brien said...

Hmm, that sounds to me as though perhaps the old assembly is being in the .wsp?

What happens when you rename the .wsp file to a .cab? You can then 'Extract' or 'Copy' to access a file in the package - is the assembly that's being built into the package definitely your updated version?

C.

Kate said...

Turns out I had the output location for my build set to the wrong place so you were correct that my dll included in the cab wasn't the correct one.

Ok so I'm hoping this is my last question...

When I upgrade the solution, it gives me a Error: File Not Found page for default.aspx I have no idea how to troubleshoot this and figure out what file cannot be found... also, I don't know why this would happen when i haven't deleted anything... :(

Chris O'Brien said...

Hmm, not sure about that one I'm afraid.

If you need to include a file in your Solution you might need to use the 'Module' and 'File' elements to provision the file in the right location.

Are these elements in the elements file in the original .wsp? You can check by renaming to .cab and examining the contents again..

C.

Anonymous said...

Chris

Thanks being the Angel of Sharepoint problem solver. The fact you take time to reply to these blogs in itself tells that you deserve kudos and laurels. We appreciate your effort, time and patience.


This blog really helped me to understand the deployment process. As I was reading it, it crossed my mind what a little fact I missed. All well, now my webpart works.

(I am using VS2005 Sharepoint templates for Visual C#) and it creates the .wsp and setup.bat file automatically. All you need is to take these two files and put it on server(dev, test etc) in a directory and then run the setup.bat. That deploys the webpart fine.) :)

Thanks again.

bk201173

Chris O'Brien said...

bk201173,

Thanks for your feedback! I really really appreciate it. Sometimes it's difficult to know if the information is useful, so it's good to hear from people.

Thanks for taking the time to comment.

Chris.

Anonymous said...

Chris need your help please...

I am doing my development on a VM and I am using VS2005 Sharepoint
templates. On my laptop(lclt011296) on C:\, I have a .mdb file. When in VM (the VM sits on my laptop), I
use a VS2005 project on VM, I can make a copy of the access file of the original,
and read from the copy and delete it using fileInfo class from VM. But when I try the
same from the webpart.cs on VM, I get an error that it cant find the file.

For example this works in the normal VS2005 project
1. FileInfo fiInfo = new FileInfo("\\\\lclt011296\\d$\\DATA.mdb");
2. fiInfo.CopyTo("\\\\lclt011296\\d$\\CopyData.mdb", true);

But in my webpart project, line 2 errors saying "cannot find file
\\lclt011296\d$\data.mdb"

So my question is, why am I getting that error through the webpart execution
and what username does the webpart get executed so I can grant proper access
to the network .mdb file.

If my explanation is not clear, please let me know.

Any help is much appreciated. Thanks.

Chris O'Brien said...

OK, so you've tested the code in your web part runs in a non-SharePoint context - that's an important test I'd say, we now know that the code is OK but something 'SharePoint-related' is the problem.

The web part code will run under the identity of the IIS application pool which the site has been configured to use. You should check that this account has appropriate NTFS permissions to the file.

Also consider that if the assembly for your web part is not in the GAC (i.e. it is running from the site bin directory), it will not run with Full Trust by default. However, if this was the issue I'd expect to see a security exception rather than the "cannot find file" error you are seeing.

HTH,

Chris.

AC said...

Chris-
Thanks for referencing my article. I hope to have a more extensive solution and updated post very soon.

-AC

Anonymous said...

Hi Chris,
Thanks for the great article. Actually I have some doubts regarding the wsp files. i am using SharePoint Solution Generator to create and deploy the solutions. My Doubts are
1. In SP, I am creating a Web Application and then i am deploying the solution. When i deploy this is available as a site template and by deploying it is not automatically creating a site. Right? We have to explixitly go and create a Site collection by selecting this Template. Please correct me if i am wrong. After creating the site, i am able to see all the custom lists created by me.
2. Now i have a problem. Imagine in the dev environment i have modified one of my custom list and I have added an extra column to it. Now this change has to be deployed to the production. How can wsp technique help me in this.I tried creating the Site definition again and tried to upgrade the solution. but that does not seem to work,
Any help will be appreciated.

Thanks
Sowmya

Chris O'Brien said...

Sowmya,

In answer to your questions:

1. Yes you're absolutely right. Deploying the site definition only makes it available for use, it doesn't actually create any sites with it. This is another step.

2. In terms of updating items deployed as part of a site definition, it's not a good idea to go back to the original site definition to make the change. If this is now in use you could break things. See my article on Creating, deploying and updating custom site definitions for more details on this.

Generally speaking, updates to items which have already been created need to be done using the API (assuming we don't want to make the change manually through the web UI).

HTH,

Chris.

bk201173 said...

Hello Chris :) ...Greetings

Please remember that I am using VS2005 sharepoint extension templates in
developing webparts.

After much effort, I got my impersonation working and my webpart working and
got it to a deployable condition. Woof...what a journey!

Now, I have some configuration items that I specified in my solution like
username, password, path to the access(.mdb) file, a SQL Query etc which all
should be configurable at deployment time.

How do I specify these as configurable items during deployment so that
somebody(say QC or admin during deployment) can change it?

Thanks for your help

Chris O'Brien said...

Hi bk201173,

That's an interesting question. Unfortunately there isn't really anything specific in the deployment framework which allows you to separate out config values this way. The only thing that springs to mind is that properties can be passed to Features and the values can then be used in a Feature receiver, but that doesn't sound like what you want to do.

Hence I think you need to look at general .Net techniques for storing config values. You can use the ApplicationSettings section of the web application's config file, and there is special provision for named connection strings. In my organisation we often store config values in a special SQL table, which is cached in memory for fast retrieval. But there are many other options.

Hope that's of some use!

Chris.

bk201173 said...

I am at Wit's end...and I dont know what to do. I thought may be I will do customizable properties of web part, but then realized, the webpart wouldnt even show up because the conn settings are missing, so, let alone how can I set the properties if it errors. And I am correct in saying this right?

Web.config file...that sounds like a good idea. May be I can put my own section and read from it? dont know...will investigate that idea.

The other way may be is to deploy an xml file with config info with the solution and read from that?

Thanks Chris for all your help.

Chris O'Brien said...

bk201173,

Using the web part properties for your config could be a good solution. You'd need to consider the following though:-

- your code would need to be written so that the web part does not error if the config values have not yet been entered
- the config would need to be entered every time a user added the web part to a page. Unless that is, you added a pre-configured version of the web part to the web part gallery for them to use.

Otherwise yes, reading from the web.config file or a custom XML file are common solutions. In terms of web.config, as I mentioned the AppSettings section is provided for this purpose. It is also possible to use custom sections (though this is more work to implement).

Best of luck,

Chris.

Collin Ames said...

Chris -

I note from your script file above that you appear to be deactivating and retracting a solution, then readding it rather than using the upgrade solution route. Is this particular to the web part example, or a general rule?

I ask because I've been working with a master page/page layouts feature for our intranet and it seems that once a file is in use, it doesn't upgrade. This is true of the layouts and the css files. Now, it appears that I can manually upload the replacement files, but this isn't a great idea in a multiple site environment, I'm guessing.

Thanks again for your support.

Chris O'Brien said...

Hi Collin,

I tend to use the deactivate/retract/deploy/reactivate sequence because I know it works and I noticed that's the process VSeWSS uses. I figure MS may well have developed WSeWSS to work in this way for a good reason. That said, I'm also fairly sure the upgradesolution route shouldn't actually make much difference, aside from the solutions being versioned inside the solution store.

I actually think your problem could be down to something else. I'm thinking you might have deployed your master pages and CSS files as features, and later used SPD or the browser to make a change which involved a check-out/check-in. This would cause the files to become unghosted or customized, and future updates via features will not work. See my article Considerations when using Features to deploy SharePoint files - ghosting/unghosting for more info on this.

HTH,

Chris.

Anonymous said...

Great post. One question now...

Is there a way, when I deploy my webparts, to deploy a couple sample pages that have pre-configured webparts?

Thanks.

Chris O'Brien said...

Hi,

Yes this is possible. Have just looked over the articles I wrote and don't seem to have covered this anywhere, so I'll try and explain it here.

What you need to do is:

1. Obtain the web part definition with the settings you want to use, i.e. by adding the web part to a page, configuring, then exporting the webpart. This will give you the .webpart file.

2. Assuming you're deploying your page which hosts the webpart using a Feature (you need to be), within the 'File' element in the Feature's elements file (often named 'elements.xml'), add an 'AllUsersWebPart' element. Suggest checking the documentation for this, and also perhaps having a look at Deploying master pages and page layouts as a Feature if you're not familiar with deploying files using a Feature.

3. Drop the contents of your .webpart file into the 'AllUsersWebPart' element.

4. Deploy using your normal approach, e.g. using a Solution package

Note that all the pieces for the web part (assembly, SafeControls entry etc.) need to be deployed for everything to work successfully.

HTH,

Chris.

chris b said...

Hi Chris
I just discovered your blog the other day, it has been a huge help. Thanks for taking the time to write all this.

I have 2 questions:
1. when I create a .CAB using VS's built in deployment project (as part of a solution containing my webpart) it creates a *.OSD file. When I create the .WSP using the cab sdk, it does not. Is that file needed? In "Developer's Guide to Windows Sharepoint Services 3.0" Bleeker keeps it in his, but I don't see it generated. I can deploy to a single-server "farm" and it works fine.

2. On the multi-server farm, my solution is not being deployed to all web front ends on my farm. It only goes to one: the server that Centeral Administration services is running on. Do you have any guesses on where to look to troubleshoot this?

thanks

Chris O'Brien said...

Chris B,

Thanks for the feedback.

Hmm, I'm not really familiar with using VS deployment projects to generate a .cab. I know it's possible, but seem to remember there are issues if you wanted to include localized resources in the package. However, I do know that a .OSD isn't used by SharePoint as such, so there's no dependency there.

In terms of why your solution is not going to the WFEs, I'm wondering if you're deploying to the correct URL? This should be the actual content site URL, not the Central Admin URL..

HTH,

Chris.

Chris B said...

Hi again. We're using the right url, and seem to be creating the .WSP correctly. Once in a great while it works and deploys to both WFEs, but most of the time it does not work. That is what is so crazy, if it never worked I'd keep thinking I'd done something wrong, but sometimes it does. It almost always only updates the WFE with central admin running, no matter how many other applications I try to deploy to (choosing different urls), or using the central admin screen to deploy to them all. It will deploy to all the applications, but most of the time only updates the server running central admin, not the other.

So now I wonder if something else is wrong with our server setup.

Anonymous said...

this is a great article and explains very well. The killer for me is that although you wrap a solution around a feature and get it deployed and upgraded easily with rollback, if now upgraded feature is disabled and re-enabled, and attempts to override an existing file it either does not, or barfs depending on the IgnoreIfAlreadyExists directive. Can you think of a clever way to deal with this?

Chris O'Brien said...

This is something I've only just become aware of, thanks to Daniel McPherson's post about this.

However, I can say that my changes to my files happen OK on feature re-activation when the file in question is not customized (unghosted). This is a key point as the file on the filesystem (i.e. the one the feature overwrites) will not be referenced if it has been customized - instead the version which was put into the content database will be used.

Additionally, I've not tested updating a file from a different feature to the one which originally provisioned it.

Assuming those two factors are the same for you (file not customized, update from same feature), I'm pretty sure your file should upgrade OK.

Cheers,

Chris.

Anonymous said...

Hi Chris:

A great post. I am having a problem that deals with referencing the site url. The web application has SSL encryption and although I can add the feature OK it will not let me deploy the feature. I first tried to resolve to localhost, then the hostname, and finally the https url without success. Do you have any suggestions where I might look to fix this problem.

Thanks again,

Val D.

Chris O'Brien said...

Hi Val,

You should always reference the site using the same address you'd use in the browser. Remember though, that whilst solutions are deployed to a top-level site (http://testsite), you may have Features scoped at the web level so these may be at a different URL (http://testsite/childsite).

HTH,

Chris.

Anonymous said...

Hi Chris, well presented..
Thanks a lot for this blog

RameshSubburaj

Anonymous said...

Hi Chris,
I'm deploying a feature with a WSP file that was built from a ddf file and then compiled using Makecab.
Does anyone know if it is possible, and if so, how to include registry entries and extra web.config keys to the solution?
Any examples would be very useful,
Thanks
Andy

Chris O'Brien said...

Hi Andy,

Couple of notes:

- web.config keys you can do as part of the .wsp deployment - the technique is to use the SPWebConfigModification class in code to add your entries
- there's no support for adding registry entries, but you might be able to do it in code somehow, perhaps in a Feature receiver which is in your solution

I have a solution which uses these techniques at www.codeplex.com/SPConfigStore, but note there's a minor bug somewhere which means the web.config changes aren't rolled back when the solution gets retracted (they should be). Suggest also checking out Vince's tool at http://blog.thekid.me.uk/archive/2007/03/24/web-config-modification-manager-for-sharepoint.aspx.

HTH,

Chris.

Anonymous said...

I need to give full trust to a dll without deploying it to GAC. How can I do it through Code Access Security config modifications in manifest.xml. It does not recognize "Unrestricted=true" in PermissionSet in PolicyItem in
Code Access Security section.
Please tell me how can I grant full trust to this dll.

Chris O'Brien said...

Hi,

It's been a while since I've done CAS, so afraid I don't have a definitive set of steps for this. However, the following links might be useful:

- http://weblogs.asp.net/jan/archive/2005/06/23/WebPartSecurity.aspx - a SharePoint 2003 article but has good detail on the policy XML required. You'd need to adapt to working with SharePoint 2007's Solution framework (wsp)
- http://store.bamboosolutions.com/kb/article.aspx?id=10405
- http://daniellarson.spaces.live.com/blog/cns!D3543C5837291E93!1963.entry?sa=849563486

I'd start with those.

HTH,

Chris.

Anonymous said...

Hi Chris,

Can you help me to deploy .JS and .css files as a package include with the feature package? Deploying webpart as a feature is working for me . I need to add .js and .css file's as required for the webpart.
Thank you

Chris O'Brien said...

@Anonymous,

Sure you can do this. If you are building the Solution manually as I describe in this article, you should add lines for these files to the .ddf file. If you're using WSPBuilder (perhaps a more modern approach compared to this article), the files should be picked up and packaged if they are in your 12 hive structure.

HTH,

Chris.