Archives

Archives / 2010 / August
  • Understanding folders and namespaces in Visual Studio 2010 SharePoint Solutions, Packages and Features

    Tags: Visual Studio, SharePoint 2010

    Yesterday Todd Bleeker (SharePoint MVP) wrote a post about the SharePoint Project SPI's where he explains how SPI effectively are folders within a SharePoint solution. I thought that I should continue that discussion a bit and looking at how these folders and other things such as packages and features affects the actual deployed artifacts.

    Packages

    Badly named project :-)A package (#3 in the figure to the right) is the actual WSP file that will be created containing all your objects from your solution that will deployed to the SharePoint application servers. The project can only contain one package.

    The package is by default named as your project (#1), that is in this case it gets the name AnotherSharePointProject.wsp.

    If you are using longer names on your projects, such as including client name, purpose of the project etc and  you feel it is to cumbersome to remember or type in when deploying. You can then use the Package designer to give it another name, without changing the project name. Double click on the package and edit the name in the Name textbox. Easily done!

    Features

    You use features (#2) to collect and target your artifacts to different scopes, such as Site Collection, Site or Farm. When you add an SPI to the project and you do not have any Features created; then Visual Studio creates a default one for you. What is important here is that each feature will be unpacked from the Package and copied to the SharePoint Root TEMPLATE\FEATURES folder on each SharePoint application server. FEATURE folderThe name of the folder will be a combination of your project name and the feature name. It will not use the name of the package. So for the sample in the image above it will be named AnotherSharePointProject_Feature1.

    Once again long names can make this not look good and there are path name length restrictions (260 characters I believe, can anyone confirm). Remember that the path to the TEMPLATE folder is about 90 characters and you should have space left to place your SPI produced items within the folder as well.

    SharePoint Project Items

    As Todd describes in his post, each SPI is a contained within a folder (#4). The folder has the name of the SPI. And what's annoying is that the namespace of the SPI items is based on that folder name as well. So if you create a Web Part with the name WebPart5114, then the SPI will be called WebPart5114 as well as the folder, the class file and the Web Part class itself. This leads to a full name of the class like this: AnotherSharePointProject.WebPart5114.WebPart5114. I previously blogged about this (unfortunately bad) design which is not allowed through the code analysis without a warning (CA1724). Do not change the namespace unless you really know what you are doing!

    Tip: you can workaround the namespace problem and write your own namespace, for instance for a Web Part. Just make sure that you update the Web Part Control Description file (.webpart), and even better use the [Guid] attribute and replaceable tokens in it like described in an earlier post, in case you change it again. (Should have been like that OOB IMHO.)

    This SPI folder will end up beneath your Features folder in the SharePoint Root with the same name as the SPI, as in the figure below. The files in this example have an approximate path length of 150-160 characters.

    SPIs in FEATURES folder

    Renaming an SPI only affects the name of the SPI and the folder in the FEATURES folder. It does not change the namespaces or class names of a Web Part for instance.

    Nested SPIsYou can also nest SPI's to group them better together or use project folders. Fortunately(?) this has no impact on the resulting files and folders in the FEATURES folder.

    Summary

    You should carefully think of how you are naming your projects, packages, features and SPIs. You should make sure that you change the name of your features so they are not called Feature1, Feature2 etc., since this will end up in the FEATURES folder and having thoughtfully selected names makes it easier to find information and troubleshoot problems.

  • How to create a SharePoint 2010 application using Visual Studio 2010 LightSwitch

    Tags: Visual Studio, SharePoint 2010

    Visual Studio 2010 LightSwitch is a new kid on the block in the Visual Studio suburbs. Basically it is a rich client application editor for Visual Studio that allows you to develop (or should I say "click-through") an application very easy without any programming skills at all. You can create a custom database, attach to an external data source or WCF RIA service and last but not least hook it up to SharePoint. And this is what I'm going to give you a quick peek at.

    Install LightSwitch

    First of all you need to install Visual Studio LightSwitch (I do not recommend to do it on your primary machine, as of now, since it is beta - I did it though). I failed a couple of times until I uninstalled the already existing pre-requisite WCF RIA Services and re-tried the LightSwitch installation.

    Installing LightSwitch

    Create a LightSwitch application

    Once it is installed you are ready to create your first application. Start Visual Studio! LightSwitch installs as a project template in Visual Studio if you already have it installed. Select to create a LightSwitch project using one of your favorite languages; C# or Visual Basic. We're going for C# here (even though we're not going to write a single line of code...).

    LightSwitch project templates

    If you have been building SharePoint 2010 solutions previously using Visual Studio, your Framework dropdown is most certainly set to .NET Framework 3.5. Switch that to 4.0 to see the project templates for LightSwitch.

    Connect to your data source

    Connect to data sourceOnce your project is created by Visual Studio you have the option to create a new data source or connect to an existing. Since we will connect this application to SharePoint; select Attach to external database.

    You will then be presented with a wizard where you can choose the type of data source you would like to connect to. You have the following options; Database, SharePoint and WCF RIA Service. We'll go for SharePoint, of course!

    LightSwitch data sources

    SharePoint ListsNext you have to provide the address to the SharePoint site you would like to connect to and how you are going to log in (current credentials or custom). After clicking Next (it's a lot of next-next) you will see all the available lists in the SharePoint site you specified.

    Choose the list or lists that you want to use in your LightSwitch application, as in the image to the right.  When you are done click Finish to complete the wizard. If you have tables using lookups you will get a warning that says it will include these lists in your app as well. As the matter of fact you will always get this warning for SharePoint data sources since all lists contains created by and modified by which are connected to the user information list. Accept the warning by clicking Continue. Depending on how your lists are built you can get other warnings here as well, read the thoroughly and act accordingly.

    When the wizard is finished you will see the designer of your application (see image below). You will see all the lists (tables) and the relationships between them. You can also configure the tables and relationships here. For instance you can configure validations and appearance.

    image

    If you need to add filters, sorting or parameters to the lists this is done by clicking on the Query toolbar button. Also if you want additional columns you can use the Computed Property toolbar button to add custom columns. You can then calculate these in your code behind for the app (but no code this time as I earlier said).

    We will make a small change here and change the default property of the user information list. Double click on the UserInformationList entity in the designer and then select the entity and view the properties (F4). As you can see in the Appearance group, the default property is the ContentType column, duh!. Change that to Name instead.

    Properties of a LightSwitch entity

    Build the interface

    LightSwitch UI templatesSo now you have the data and you need some interface for this. It's just as easy as clicking on Screen toolbar button. When this button is clicked you will see a dialog that allows you to choose from a set of pre-defined interface templates. In this case we select the List and Details Screen. Then in the Screen Data drop-down select the data source which should be the list (or one of the lists) that you choose in the wizard. Also check the checkboxes to include additional data and finally click OK.

    When Visual Studio has finished loading you will see a hierarchical view of the interface - very much like the control tree of a WPF application. Depending on which template that was previously selected the default control tree looks different. It is this control tree that controls the magic of LightSwitch.

    LightSwitch control tree

    Change column in LightSwitchTo customize the default experience a bit we'll do a small change to the application. The selected data source only shows the Summary Property of the items (just as we changed for the user information list). To show all columns instead it is as easy as switching the Sales node of the left column from Summary to a horizontal stack. LightSwitch will then add controls in the tree for all the columns in the list. You can then of course remove those you don't want in the list.

    Take it for a test drive

    I think we are good for a test drive now. Hit F5 and wait for your brand new application to start. Voila!

    Done!

    You can now easily browse the list and check out the details of each item. You can even edit the rows and persist the changes back to SharePoint.

    Conclusion

    So what's the big deal here? LightSwitch allows you to very easy and fast create an application (using this even Todd Klindt can call himself a developer).

    But. There is always a but..

    Even though Microsoft is all in for LightSwitch, I have hard to see where it actually fits. It's a little bit to "technical" to let this app loose amongst your business users and far to LightWeight for an advanced developer. We've seen how easy it is to do the same thing in Silverlight or WPF. Under the hood LightSwitch uses the SharePoint REST services (/_vti_bin/listdata.svc) so basically any other "data-wizard" in Visual Studio can do the same magic. It very much feels like a hybrid of Access and Visual Studio and I would have preferred to see this integrated to Access than into Visual Studio - that would (IMHO) be a far better experience for business users.

    Then we have another problem with these kind of apps (just like Excel, Access etc) - if the users adopt this tool they will create another stack of data sources (if they don't use SharePoint as data source and instead create new ones) that eventually becomes necessary for the business - which leads to that they must be backed up, migrated, integrated, you name it into SharePoint or other systems.

    As of now I can't see the business case for a professional developer to use this tool. But it's ok - and for some it looks like magic...perhaps it might be used as a prototyping tool?!

  • Upcoming speaking engagements - Stockholm to Singapore

    Tags: SharePoint 2010, Presentations

    Summer is not yet over (at least not according to the calendar) and this autumn is already being planned and filled with some great stuff. Part from working on a great SharePoint 2010 project, waiting for the book to be ready and some other stuff I also have planned a few speaking events - which I'm really thrilled about.

    SharePoint and Exchange Forum 2010

    Stockholm - 18th-19th October

    SharePoint and Exchange Forum 2010For the second consecutive year I will speak at the largest SharePoint and Exchange event in Scandinavia, arranged by my good friend and SharePoint MVP Göran Husman - the SharePoint Exchange Forum 2010 (#SEF). I will do a session called Playing in the Sandbox where I discuss the SharePoint 2010 Sandbox and how you can use it and how it affect you as a developer. There will be a lot of good speakers and great content - and if you're around I hope to see you there!

    Southeast Asia SharePoint Conference 2010

    Singapore  - 26th-27th October

    Southeast Asia SharePoint Conference 2010I will be travelling down to Singapore for the Southeast Asia SharePoint Conference (#SPCSEA) and do two sessions about SharePoint 2010 - Playing in the Sandbox and SharePoint and Silverlight - new BFFs. This is a great event organized by Steve Sofian (MVP), Randy Williams (MVP) and Debbie Ireland. This will be the conference to attend to in the Southeast Asia if you are in to SharePoint! Early bid is only $SGD 300 - so hurry! I'm really looking to this event and to meet up with the great lineup of speakers ranging from local experts and MVPs to international SharePoint superstars. For you attending - how about a SharePint at Raffles?

    That's what I have planned for now. And for sure you will see me at some upcoming local SharePoint User Group meetings.

  • About the SharePoint 2010 certifications

    Tags: SharePoint, SharePoint 2010

    A little more than a year ago I wrote a post after finishing all four SharePoint 2007 exams called "70-640 passed! Do you really call this a certification!". I thouht the exams were to easy and did not say much about your SharePoint skills at all and I had hopes for the new SharePoint 2010 exams. I did hope that they would stop focusing on IntelliSense and API knowledge and more focus on best practices, design decisions and problem solving. Unfortunately I can't say that my hopes became reality.

    The SharePoint 2010 exams have been improved (apart from focusing on 2010 instead of 2007). Instead of having four Technical Specialist (TS) exams and focusing on SKU's, there are now two Technical Specialist exams and two Professional exams (MCPD and MCITP). One track for developers and one for IT-professionals, see image below. To achieve the Professional titles you have to succeed on the TS exams first.

    SharePoint 2010 certifications

    The TS exams (573 & 667) are just as bad as previously, even though the Configuring (667) exam is slightly better. The PRO exams (576 & 668) on the other hand are actually worth (at least) something, especially the Administrator (668) - which I think is the most interesting of them all.

    I did all four of these exams during the beta period, in which some questions were really weird and dubious. For the 573 exam (Intellisense exam) I had the great joy of taking it twice - beta and final release, due to that Prometric "lost" my exam and then claiming I did not show up (even though I got a receipt for it).

    No show!

    So why taking these exams you might think? Some people I know refuse to take them just because they are to easy and they say nothing about your skills. But for me there are many reasons for this. First of all I am a consultant. Many clients I meet have no idea about SharePoint and its technology - having a few certifications to show opens the door faster and they believe in the validity of the certifications. Secondly I am a Microsoft Certified Trainer (MCT) - some classes requires that you have the certifications and most students take the classes to later take the exams - then I think it's good to know what the exams contains. There are more reasons for taking them such as your company will get Microsoft Partner points, some companies also pay a bonus for achieving new titles, you need them to even apply for the Certified Masters program etc etc, the list can go on. I think that you should at least try them - you might even learn something!

    To sum it up - if you're into the SharePoint business - there is no harm in taking these exams. You could do it the easy and fast way as Bjørn Furuknap shows or you can do it because you want to learn more about the amazing product SharePoint. The first SharePoint exams that I took really gave me time (forced me) to study on all areas of SharePoint (workflow is still my weakness, got to read Phil Wicklunds book about it soon).

    So this is my 2 cents (or ören as we say in Sweden) of these exams - and here I am with nine different SharePoint exams (TS in SharePoint 2003, 4x TS in SharePoint 2007 and 2x TS plus 2x PRO in SharePoint 2010). And I like it!

  • Minifying custom JavaScript files in SharePoint 2010

    Tags: Visual Studio, Scripting, AJAX, SharePoint 2010

    As you know the usage of JavaScript has been more and more used in web applications over the past years for technologies such as AJAX. JavaScript can accomplish really cool stuff on the client side and make the user interface more interactive and responsive. Just take a look at SharePoint 2010 - that's some heavy JavaScripts there (a bit to heavy IMHO).

    So lets assume that you are building some new cool stuff, in SharePoint of course, and why not a Page Component for a contextual Web Part. That's a lot of JavaScript (apart from the server side XML chunks)! So now you are making your web page payload even heavier. This is when minifying comes in. Minifying is a way to minimize the payload of a resource such as removing unnecessary comments and whitespace, shortening function and variable names etc - all to make the payload as small as possible. The only problem with these minified scripts are that they are virtually impossible to debug (and believe me if you are building a Page Component for SharePoint - you need to debug).

    If you have noticed SharePoint 2010 supports production and debug JavaScripts side-by-side. When you are debugging your SharePoint site you will see that all JavaScript files have a name like SP.debug.js, SP.Ribbon.debug.js etc. These are files that you actually can debug (even though they are obfuscated somewhat). All this is thanks to the SharePoint ScriptLink control which loads the production or debug version depending on if you are debugging or not.

    To use minified JavaScrips (or CSS files) in your SharePoint 2010 solutions you can do it easy with the Microsoft Ajax Minifier 4.0 and a pre-build event in Visual Studio 2010. Just follow these simple steps when you have installed the Minifier.

    Layouts folderCreate a new SharePoint 2010 project (farm solution - ScriptLink is not supported in the Sandbox)and then add the Layouts SharePoint Mapped folder to the project. Add two empty JavaScript files to the folder that is created. One with the .js extension and one ending with debug.js.

    Add some smart JavaScript code to the debug.js file - this is the file that you will edit from now on. The .js file will automatically be updated with the minified code. Then head on over to Project Properties and the Build Events tab. In the pre-build event enter the following:

    "C:\Program Files (x86)\Microsoft\Microsoft Ajax Minifier 4\ajaxmin.exe" 
        -JS $(ProjectDir)\Layouts\Wictor.Minified\TheScript.debug.js 
        -out $(ProjectDir)\Layouts\Wictor.Minified\TheScript.js  
        -CLOBBER

    This will before building the project invoke the Ajax Minifier and create/update the minified JavaScript file. The -CLOBBER option allows the minifier to overwrite existing files. Replace the file name and folder with your file name and folder.

    Then add a Visual Web Part to your project and add code as follows:

    <SharePoint:ScriptLink runat="server" Name="Wictor.Minified/TheScript.js" Localizable="false"/>
    <asp:Button runat="server" Text="Click me!" OnClientClick="thisIsMyFunction('Hello mini!');" />

    The ScriptLink control will load the correct version of the script. Notice that you do not specify the debug version. Also Localizable is set to false here, since this is not a localized JavaScript (the Ajax Minifier actually supports localization of your JavaScripts - cool huh).

    Make sure that your SharePoint web application does not have debugging configured in the web.config and hit Ctrl-F5. This will start Internet Explorer and you can add the Web Part to a page. Then take a look at the source and look for your script. It should look something like this.

    Uses minified JavaScript file Then you go back to Visual Studio and compare the two JavaScript files. In my case it looks like this:

    Visual Studio 2010 comparing JavaScript files

    The debug JavaScript is 380 characters and the minified is only 147!

    Then hit F5 to run the project in debug mode and inspect the source of the page. You can now see that the debug version is loaded.

    And now in debug mode...

    That's it! Simple! Now go on minifying!

  • Nifty trick with Visual Studio 2010 replaceable parameters for SharePoint 2010 Web Parts

    Tags: Visual Studio, Web Parts, SharePoint 2010

    MP900408848[1]If you have been working with SharePoint 2010 development using Visual Studio 2010 you have most certainly stumbled upon the new replaceable parameters that replaces data in your solution files during the packaging process. For instance Visual Studio uses $SharePoint.Project.AssemblyFullName$ in the Web Part control description (.webpart) files and this is replaced with the assembly full name (strong name) during packaging. By default it looks like this when you create a new Web Part:

    type name="Project.MyWebPart, $SharePoint.Project.AssemblyFullName$" />

    After the packaging and when deployed into SharePoint it looks like this:

    type name="Project.MyWebPart, Project, Version=1.0.0.0, Culture=neutral, PublicKeyToken=54c0c201dd8d1c31" />

    This saves you some time when changing versions etc of the assembly.

    But what about if you change the name of the class or the namespace, then you have to rename a whole lot of things; the CS file, the .webpart file, optionally the element manifest and of course all references. A better way is to use another replaceable parameter that replaces the token with the full name of the type. First of all you need to specify a Guid attribute on the type (Web Part class in this case) like this:

    [ToolboxItemAttribute(false)]
    [Guid("A4D3BE9B-E2D6-42A4-B4F9-D78911C214E8")]
    public class MyWebPart : WebPart{...}

    Then you update the .webpart file to use the replaceable parameter that has the format of:

    $SharePoint.Type.GUID.FullName$

    The GUID must be lower-case and your updated .webpart file should look like this after copying the Guid value from the attribute:

    type name="$SharePoint.Type.a4d3be9b-e2d6-42a4-b4f9-d78911c214e8.FullName$, $SharePoint.Project.AssemblyFullName$" />

    Visual Studio 2010 will now replace this during runtime with whatever you Web Part class name and namespace is, so you can feel safe renaming and refactoring.

    Even better is that this works for all other cases where you need to reference a type in an element manifest, user control or similar. Out-of-the-box the following file types will be parsed and parameters replaced; XML, webpart, DWP, ASCX and ASPX. For instance you might have added a event receiver for a content type - just add the same two tokens used in the sample above in the Assembly and Class elements of the Receiver element.

About Wictor...

Wictor Wilén is a Director and SharePoint Architect working at Connecta AB. Wictor has achieved the Microsoft Certified Architect (MCA) - SharePoint 2010, Microsoft Certified Solutions Master (MCSM) - SharePoint  and Microsoft Certified Master (MCM) - SharePoint 2010 certifications. He has also been awarded Microsoft Most Valuable Professional (MVP) for four consecutive years.

And a word from our sponsors...

SharePoint 2010 Web Parts in Action