Creating SharePoint Solution Packages! So easy an Admin can do it!

Originally posted on: http://geekswithblogs.net/SoYouKnow/archive/2010/07/08/creating-sharepoint-solution-packages-so-easy-an-admin-can-do.aspx

First of all, I must apologize for letting my blog go fallow… pretty good use of ‘fallow’ though, right? I mean how often do you get to throw that word around? I guess playing ‘Farmville’ wasn’t a total waste of time!

Anyway, I’ve been up to my elbows in projects and family time and have just not had a chance to blog lately. So… where to start… oh yeah… Stop copying files directly to the 12 hive! Seriously.. I don’t care what the file is… custom controls? java script files? images? web parts? If you are copying it to some sub folder under the 12 hive directory, then stop it! It’s bad practice, a pain to maintain, and it will bite you in the rear at some point. I don’t even like doing it on my dev VM.

Isn’t this a dead horse that has been beaten beyond recognition?

So, yeah. This is an old topic and people have pretty much settled on whether they are going to create packages or not for the most part. But I got a question from an admin/developer friend of mine the other day that wanted to test some JavaScript files and she asked me if she needed to copy the files to every Web Front End. This made me scratch my head. Why is she just not creating a solution package for these files? That way SharePoint handles putting the files where they go AND you can easily retract the files if it doesn’t work. The answer is simple, she didn’t realize how easy it was to create solution packages! Many people just find it too daunting to create all the XML files or even knowing WHICH files need to exist and the file structure. Let’s face it, unless you are developer you most likely don’t have these file formats memorized. Isn’t it just easier and faster and better to copy the files over manually? Why waste the time? right??? NO!!! Not Right… give me your “Geek” card right now.

But it’s such a pain to package everything…

No.. it’s not… it’s REALLY not. There are some great tools out there to aid you and you don’t have to even open an XML file. With a couple of drag and drops you have a package ready to deploy.

It’s just so much faster to copy the files…

Maybe on a single WFE instance it is, but otherwise.. no… it isn’t. When you take into account that you have to copy your files to every WFE and make sure they stay in sync it can quickly turn into a non maintainable mess. Why go through the headache when you can deploy and retract a solution as needed? It will automatically get put on every WFE and they will stay in sync… ugh… thank God boy bands are gone by the way…

But I don’t know HOW to package these files…

Stop your whining! Why do you think I created this blog?

So, let’s get started then…

What tools do I need?

So, you’ll need to download a couple of tools.

STSDev – Yes.. STSDev.. I know there are other tools out there, but I still have not found a good reason to use any of the others. These guys did a tremendous job of doing all the heavy lifting for you in this tool. You can download it from CodePlex here: http://stsdev.codeplex.com/

A SharePoint Dev Environment with Visual Studio – Don’t have / can’t afford one? No worries, Microsoft has a VHD you can download with Visual Studio already installed. It bombs after 30 days, but you can just use it over and over for 30 days. Hey, you gotta start somewhere? right? You can find the 2007 VHD here: http://www.microsoft.com/downloads/details.aspx?FamilyID=67f93dcb-ada8-4db5-a47b-df17e14b2c74&displaylang=en If you already have a SharePoint Dev environment, but not Visual Studio, you can try downloading the Visual Studio Express version and use it. It can be found here: http://www.microsoft.com/express/Downloads/#2010-Visual-CS Now, I have NOT confirmed that STSDev will work with the Express version, but I don’t know why it wouldn’t. I’ll try and confirm this for you, but don’t hold your breath. 😀

So, install Visual Studio if you haven’t (I’m using VS 2008 on my VM, so my screen shots will reflect that), then install STSDev.

All set?

Let’s create a solution package!

You need two more things to create a package.

A file to deploy
The location to deploy it to.

So, got any ideas for this learning exercise? Here’s a common problem. Many people want to get rid of the “My Settings” link on the user menu. There’s some JavaScript out there to do this, but I hate relying on JavaScript because it’s so easy for someone to get around it. You might be thinking Custom Action, but I have not been able to get that to work (nor have I found anyone successfully removing that link with a custom action). So! What can we do? The best solution I have found is to take the Welcome.ascx user control that the Master Page uses and create a new control. This is actually very easy. Grab the Welcome.ascx file from the 12 hive here: C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\CONTROLTEMPLATES. Rename it to CustomWelcome.ascx (or whatever you want) and modify it so it looks like:

<%@ Register Tagprefix="SharePoint" Namespace="Microsoft.SharePoint.WebControls" Assembly="Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %> <%@ Register Tagprefix="Utilities" Namespace="Microsoft.SharePoint.Utilities" Assembly="Microsoft.SharePoint, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %> <%@ Import Namespace="Microsoft.SharePoint" %>
<%@ Control Language="C#" Inherits="Microsoft.SharePoint.WebControls.Welcome,Microsoft.SharePoint,Version=12.0.0.0,Culture=neutral,PublicKeyToken=71e9bce111e9429c"   AutoEventWireup="false" compilationMode="Always" %>
  <SharePoint:PersonalActions AccessKey="<%$Resources:wss,personalactions_menu_ak%>" ToolTip="<%$Resources:wss,open_menu%>" runat="server" id="ExplicitLogout" Visible="false">
    <CustomTemplate>
     <SharePoint:FeatureMenuTemplate runat="server"
         FeatureScope="Site"
         Location="Microsoft.SharePoint.StandardMenu"
         GroupId="PersonalActions"
         id="ID_PersonalActionMenu"
         UseShortId="true"
         >
         <SharePoint:MenuItemTemplate runat="server" id="ID_LoginAsDifferentUser"
                 Text="<%$Resources:wss,personalactions_loginasdifferentuser%>"
                 Description="<%$Resources:wss,personalactions_loginasdifferentuserdescription%>"
                 MenuGroupId="200"
                 Sequence="100"
                 UseShortId="true"
                 />
         <SharePoint:MenuItemTemplate runat="server" id="ID_RequestAccess"
                 Text="<%$Resources:wss,personalactions_requestaccess%>"
                 Description="<%$Resources:wss,personalactions_requestaccessdescription%>"
                 MenuGroupId="200"
                 UseShortId="true"
                 Sequence="200"
                 />
         <SharePoint:MenuItemTemplate runat="server" id="ID_Logout"
                 Text="<%$Resources:wss,personalactions_logout%>"
                 Description="<%$Resources:wss,personalactions_logoutdescription%>"
                 MenuGroupId="200"
                 Sequence="300"
                 UseShortId="true"
                 />
         <SharePoint:MenuItemTemplate runat="server" id="ID_SwitchView"
                 MenuGroupId="300"
                 Sequence="200"
                 UseShortId="true"
                 />
         <SharePoint:MenuItemTemplate runat="server" id="MSOMenu_RestoreDefaults"
                 Text="<%$Resources:wss,personalactions_restorepagedefaults%>"
                 Description="<%$Resources:wss,personalactions_restorepagedefaultsdescription%>"
                 ClientOnClickNavigateUrl="javascript:MSOWebPartPage_RestorePageDefault()"
                 MenuGroupId="300"
                 Sequence="300"
                 UseShortId="true"
                 />
     </SharePoint:FeatureMenuTemplate>
    </CustomTemplate>
</SharePoint:PersonalActions>
<SharePoint:ApplicationPageLink runat="server" id="ExplicitLogin"
    ApplicationPageFileName="Authenticate.aspx" AppendCurrentPageUrl=true
    Text="<%$Resources:wss,login_pagetitle%>" style="display:none" Visible="false" />

So, you now have a file to deploy: “CustomWelcome.ascx”. And we know WHERE we want to deploy it to because of where we copied the original from (C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\CONTROLTEMPLATES)

Okay… NOW let’s create a solution package…

Sure thing. Open up STSDev. You’ll see something similar to the following screen:

Give our solution a name… hey how about “CustomWelcome”? Make sure “Empty Solution” is checked and click on “Create Solution”. You will see a message saying your solution was successfully created. Open up that newly created solution in Visual Studio.

You will see the following message when you open the solution:

Select “Load project normally” and click on “OK”.

Now look in your “Solution” Explorer:

And let’s look at that hated manifest.xml file:

<?xml version="1.0" encoding="utf-8"?>
<!--Manifest created STSDEV utility at 7/8/2010 11:31:52 AM-->
<Solution SolutionId="031CF8A6-36ED-4F74-B043-6299A9EE78D0" ResetWebServer="True" xmlns="http://schemas.microsoft.com/sharepoint/" />

STSDev automatically created the folder structure and the XML files you need. It will also MODIFY these XML files for you as needed. Isn’t that cool? So, all you have to do to finish creating your package is to create the folder structure in the project for where our “CustomWelcome.ascx” file needs to go and put that file in the correct folder. This is also VERY easy. The “RootFiles” folder is a mirror of the 12 hive directory. Pretend “RootFiles” is the same thing as “C:\Program Files\Common Files\Microsoft Shared\web server extensions\12”. We know our file needs to be placed in “C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\TEMPLATE\CONTROLTEMPLATES” so we need to replicate this structure in our Solution. This is done by adding folders. So, let’s add a folder to “RootFiles”. This is done by right clicking on “RootFiles” then “Add” then “New Folder”.

Name the folder “TEMPLATE”. Now add another folder by right clicking on “TEMPLATE” to create the folder “CONTROLTEMPLATES”. When you are done your structure will look like:

Now all you have to do is drag and drop your “CustomWelcome.ascx” file onto the “CONTROLTEMPLATES” directory. Just open up the directory it’s in in explorer and drag and drop it there. You can also right click on “CONTROLTEMPLATES” and select Add->Existing Item and browse to your file.

When you are done you will see your file located in the folder structure.

Now… the hard part. Creating the WSP file. Press F6.

Tada… your WSP file is now created.. don’t believe me? Open up the project in your file explorer and check

Don’t believe it will work? Well, deploy it on your Dev VM by changing the Build option to “DebugDeploy”

Now Press F6 again. The package will be built and deployed on your local VM. STSDev build script will even run the STSADM commands to deploy, redeploy, retract, etc.. for you. How’s that for a time saver? So, after the deploy is finished, go look in your local CONTROLTEMPLATES directory. The file’s there? isn’t it? Seriously, wasn’t that completely easy?

If you look at your Manifest.XML file again you see that STSDev automatically modified it for you, you didn’t have to do a thing!

<?xml version="1.0" encoding="utf-8"?>
<!--Manifest created STSDEV utility at 7/8/2010 11:29:41 AM-->
<Solution SolutionId="031CF8A6-36ED-4F74-B043-6299A9EE78D0" ResetWebServer="True" xmlns="http://schemas.microsoft.com/sharepoint/">
  <!--TEMPLATE files-->
  <TemplateFiles>
    <TemplateFile Location="CONTROLTEMPLATES\CustomWelcome.ascx" />
  </TemplateFiles>
</Solution>

You can add multiple files and locations in the same solution as well. Now all you have to do is take the WSP file to your other farms and deploy it using STSADM. The files go where they are supposed to and you can concentrate on other things, like getting back to Farmville.. I’ve got to harvest my strawberries.

Conclusion

When it comes down to it, there are hundreds of “Best Practices” when it comes to SharePoint. Most people cannot agree though on what is and isn’t a Best Practice in most cases and many times the answer is “it depends”. I think this is one “Best Practice” if looked at objectively everyone can agree on. When you take into account all the benefits of creating packages it’s totally worth the few extra clicks and deployment commands.

So, stop your whining.. start packaging… it just might save the planet.

Families in Germany who are facing divers soundness problem, such persons can buy drugs from the Web without prescription. With the market flooded with divers web-sites selling sundry medicaments, purchasing medicines from th WEB is no longer a trouble for common man. Certain medications are used to treat infections caused by dental abscesses. Of course it isn’t all. If you’re concerned about erectile health problem, you probably know about Xenical and Hoodia. Probably each adult knows about Garcinia. (Read more Phentermine Xenical). The symptoms of sexual health problems in men switch on improbability to have an erection sufficient for sexual functioning. Certain medications may add to sex drive difficulties, so its essential to cooperate with your soundness care professional so that the prescription can be tailored to your needs. Preparatory to capture Levitra or other preparation, speak to your dispenser if you have any allergies. Talk to your health care provider for more details. Preparatory to ordering this remedy, tell your physician if you are allergic to anything.

MarkRackley.net

M365 Architect, Speaker, Podcaster, Developer, Blogger, Bacon Aficionado