Contents tagged with Visual Studio

  • Announcing new Visual Studio 2012 tool for JavaScript Localization in SharePoint 2013

    Tags: SharePoint 2013, Visual Studio, Downloads

    In SharePoint 2013 JavaScript is the new default language and all our (at least mine) solutions and projects are using JavaScript more and more, even though everything is not built as SharePoint Apps. Farm or Full-trust solutions built using JavaScript will in many situations create a better user interface and an improved perceived performance. The more we build user interfaces using JavaScript we cannot just forget about some of the basic UX rules, such as using localization. End-users really hate when they see mixed content in different languages. We’ve known for quite some time how to do localization server-side, but how do we do it in a smart way in JavaScript?

    Localization in JavaScript

    As always when it comes to cool stuff my mate Waldek Mastykarz already covered this topic pretty well in his post called “Globalizing JavaScript in SharePoint 2013”. In that blog post he shows how you actually can use a feature in SharePoint 2013 that allows you to get JavaScript objects, generated from RESX files, to localize the user interface. His guide pretty well covers everything you need, but I’m going to re-iterate some of it here anyways, and here is a sample on how to do it.

    Assume that you have a resource file (RESX) in your solution in a SharePoint Mapped folder (to the Resources folder). By adding a script link to the ScriptResx.ashx HTTP Handler with the resource file name and the culture as parameters you can get all the resources as a JavaScript object. For instance a simple Hello World alert in a Visual Web Part could looks something like this.

    First of all we need a resource file in the project (mapped to the Resources folder) and if you want localization, you of course have to translate it. This Resource file contains only one resource called HelloWorld.

    A Resource file

    To use this resource in JavaScript I have to write some code to load the ScriptResx.ashx HTTP Handler and pass in the name of the resource file and the name of the current culture.

    SP.SOD.executeOrDelayUntilScriptLoaded(function () {
      SP.SOD.registerSod("demoresources", 
        "/_layouts/15/ScriptResx.ashx?name=demoresources&culture=" + 
        STSHtmlEncode(Strings.STS.L_CurrentUICulture_Name));
    
      SP.SOD.executeFunc("demoresources", 'Res', function () {
        alert(Res.helloWorld);
      });
    }, "strings.js");

    In the sample above I use the Script-On-Demand (SOD) JavaScript functions to first make sure that the Strings.js is properly loaded. I need that to get the name of the current culture (String.STS.L_CurrentUICulture_Name). Then I do a SOD registration and registers the script link for the ScriptResx.ashx file using the name of the RESX file and the name of the culture. Finally I wait for the SOD to load and then shows an alert using the Res.helloWorld object.

    The ScriptResx.ashx file automatically creates a JavaScript object called Res and that object contains strings of all the resources in the RESX file. Note that the resources are using Camel Casing.

    What is the problem with this approach?

    This works fantastically great in most cases, and it is extremely hard to find anything on Waldeks posts that can be improved, but what if you don’t want to use the default namespace Res? It could be a matter of taste or a collision in names from different resource files. Fortunately there is a solution to this built into the ScriptResx.ashx HTTP Handler. You can actually specify two resheader elements in the Resource file to indicate that you want a custom namespace and the name of it – and this is exactly what SharePoint 2013 do for some of the built-in resource files.

    <resheader name="scriptResx">
      <value>true</value>
    </resheader>
    <resheader name="classFullName">
      <value>SPResXDemo.Resources</value>
    </resheader>

    The resheader with the scriptResx name attribute tells the ScriptResx.ashx handler that we would like to generate vanity namespaces and the one with the classFullName name attribute tells the handler the namespace to use.

    Unfortunately Visual Studio (not really, but the .NET ResXResourceWriter) does not handle this at all, as soon as you save your RESX file these two resheader elements will be removed. (And this is where I felt challenged!)

    SPResX to the rescue!

    To handle this situation and to be able to use custom namespaces for my JavaScript localizations I’ve created a small tool called SPResX that replaces the default RESX Custom Tool, the ResXFileCodeGenerator, and correctly preserves the resheader attributes.

    The SPResX tool can be downloaded from the Visual Studio Gallery and installed on any Visual Studio 2012 system, or found in the Extensions and updates in Visual Studio.

    SPResX in the Extension gallery

    Once you have the tool installed you just need to change the Custom Tool to SPResX and save you Resource files. You need to do this on all resource files, including the different language and region variants. Now you will get a namespace that corresponds to your default project namespace. For instance if I have a project called Wictor.WebParts, the namespace will be Wictor.WebParts.Resources (since it is in the Resources folder). If you would like some namespace that is completely different, then you can just specify that namespace in the Custom Tool Namespace. (Yes, I know you will get a notification that the file has to be reloaded – that is just the way it is).

    Configure the Custom Tool

    This is how the code from above can then be re-written using this tool, it works in the exactly same way but with a fancy vanity namespace of the resources.

    SP.SOD.executeOrDelayUntilScriptLoaded(function () {
      SP.SOD.registerSod("demoresources", 
        "/_layouts/15/ScriptResx.ashx?name=demoresources&culture=" + 
        STSHtmlEncode(Strings.STS.L_CurrentUICulture_Name));
    
      SP.SOD.executeFunc("demoresources", 'SPResXDemo', function () {
        alert(SPResXDemo.Resources.helloWorld);
      });
    }, "strings.js");

    Summary

    I hope this little tool will help somebody out there and I would appreciate feedback on it, either on this post or in the Visual Studio gallery.

  • Visual Studio 11 Developer Preview with the new SharePoint Developer tools

    Tags: Visual Studio, SharePoint 2010, Office 365

    imageVisual Studio 11 Developer Preview is now available for download für alles and it does not only include the Windows 8 stuff like the previous preview did - this one contains the thing we all want - the SharePoint Developer tools.

    Overall the performance of Visual Studio 11 is blazingly fast! I regret I tested it - since I will go back to 2010 tomorrow (or even tonight). They team has done a great job and included a lot of the PowerTools natively; such as the new Solution Explorer, the improved search feature etc.

    But, back to the SharePoint Developer tools 11! What's new for all the kool kids! Here's a few highlights.

    Content Type and List Designer

    We all love our CAML, FieldRefs etc. But it isn't that productive. VS11 contains the long awaited Content Type Designer and also a very similar designer for Lists.

    This is how the designer looks like when you're creating a Content Type:

    The Content Type Designer

    When creating a list you have a great view to create Views:

    Create a list view

    Sandbox and Office 365 support

    New features in the Office 365 space for Visual Studio was an easy bet. They have incorporated the things from the SharePoint Power Tools, such as better compile time support for the Sandbox etc. The best feature here is the Publish feature, which allows you to publish your package to a URL or local directory. You can now publish a SharePoint WSP directly to the sandbox in Office 365 - but you can't activate the solution from within Visual Studio.

    Publish!

    Other improvements

    There are much more improvements such as profiling support, better JavaScript debugging support etc. Read all about the new stuff here: http://msdn.microsoft.com/en-us/library/ee290856(VS.110).aspx

    But...you really need to test it out. I'm really looking forward to start working with projects in VS11!

  • CKSDev version 2.0 is released - includes Contextual Web Part SPI

    Tags: Visual Studio, SharePoint 2010

    Extension ManagerThe by far best utility for SharePoint 2010 developers is the CKSDev extension (Community Kit for SharePoint - Developer extensions). It's an extension to Visual Studio 2010, available through the built-in Extension Manager. To install it, just hit Tools > Extension Manager and then search for "CKSDEV" in the Online Gallery. Version 2.0 of CKSDev was released yesterday, and if you already have it installed you should have been notified about the update.

    CKSDev is a community effort involving several genius SharePoint developers that in a combined effort shares their best tools and extensions in one package. It includes everything from new project templates, project items, extensions to the built-in designers and explorers. It's just a project that you can't live or work without. You can read more about all the great features at: http://cksdev.codeplex.com. Where you also can find the source code if you're interested in building your own extensions and eventually contribute to the project.

    Contextual Web Part SPIThe version 2.0 release is a great update and contains new and better keyboard shortcuts, the WSPBuilder Conversion Tool and a set of new SPI's. My contribution, except for testing, is the Contextual Web Part SPI. This SPI allows you to easily create a Web Part with a contextual behavior, that is it has an accompanying Ribbon extension.

    To create a Web Part using this new SPI just add a Contextual Web Part (CKSDev) project item into your farm solution. Your project will get modified to include the necessary references for the Web Part and Ribbon extension to work and it will add a new SPI.

    The Contextual Web Part SPI dissected

    The SPI contains a set of files;

    • A .cs file - this is your actual Web Part class containing the necessary Ribbon plumbing
    • A .webpart file - the standard Web Part Control Description file
    • An Elements file - the element manifest for the Web Part
    • A CustomAction file - this is the Ribbon extension and it includes a new ContextualGroup with a Tab containing a Button and then necessary templates
    • A PageComponent JavaScript file - this is the Ribbon Page Component where you implement the logic for the Ribbon commands
    • A sprite image - this is a sample image containing the sprites for your Ribbon icons

    It's very easy to build your own Contextual Web Part using this. Just add the necessary business logic into the Web Part, modify the Ribbon in the CustomAction element manifest and hook up your actions into the Page Component. Don't forget to add your sprites into the composite image instead of creating tons of small images.

    This is how it (almost) looks out of the box.

    A custom Contextual Web Part

    If you find anything "funny" about this SPI - don't hesitate to get in contact with the team.

    Happy SharePointing!

  • Making every site in SharePoint 2010 into a BI Center

    Tags: Visual Studio, SharePoint 2010, PerformancePoint

    The other day I had an interesting and great workshop with a customer about the BI features in SharePoint 2010. SharePoint Insights is one thing that really gets me going - so much great stuff can be unleashed using Excel, Visio and PerformancePoint Services.

    One thing that annoys me with the default settings in SharePoint 2010 is the BI Center. A BI Center does not support the "BI for everyone" mantra - that center only turns numbers and KPI fans on. What you should do is enable BI features on all of your sites; your Intranet home page, your department sites or even on project sites etc. But it isn't as easy as you could imagine. So here's some tips for you all to BI-enable all your sites. Oh wait, don't say to your end-users that you BI-enabled their site - tell them that you have Insight enabled their site instead so you don't scare them off.

    Let's start this little excursion by enabling the PerformancePoint features and Dashboard Designer on an new Site Collection with a top-level site based on a plain ol' Team Site. Of course it is on a SharePoint 2010 Server with Enterprise features installed.

    Enabling basic Insight features

    First of all we need to make sure that the Enterprise features are enabled on your site. If not enable them on the Site Collection or enable them on all Site Collections from Central Administration under Upgrade and Migration.

    Enterprise Features

    Enabling BI-Center features

    So what is so special about the BI-Center. It contains some demo pages using Excel Services, indicators and PerformancePoint content. But most interestingly it contains the special libraries and lists used by PerformancePoint Services to store the PerformancePoint data; the Data Connections Library, the PerformancePoint Content list and the Dashboards library. These lists and libraries cannot be created directly in the web interface, the definitions for these are "hidden" inside the BI-Center site definition. This can easily be solved using PowerShell or by creating our custom Insight enabler feature. PowerShell is great; but building a custom feature allows us to either staple it onto other site definitions or allow the end-user to turn the features on or off.

    Let's create a new feature that adds the necessary lists and libraries. Open Visual Studio and create a new Empty SharePoint Project and to that project we need to add a new feature, scoped to Web. The first thing we need to do is to enable two PerformancePoint features. Since these are hidden ones, activation dependencies is out of question. Let's make it using a Feature Receiver. This feature receiver enables the PPSSiteMaster feature on the current web site and PPSSiteCollectionMaster feature on the Site Collection:

    public const Guid PPSSiteMaster = 
        new Guid("0b07a7f4-8bb8-4ec0-a31b-115732b9584d");
    public const Guid PPSSiteCollectionMaster = 
        new Guid("a1cb5b7f-e5e9-421b-915f-bf519b0760ef");
    public override void FeatureActivated(SPFeatureReceiverProperties properties)
    {
        SPWeb web = properties.Feature.Parent as SPWeb;
        SPSite site = web.Site;
        if (site.Features[PPSSiteCollectionMaster] == null) {
            site.Features.Add(PPSSiteCollectionMaster);
        }
        if (web.Features[PPSSiteMaster] == null) {
            web.Features.Add(PPSSiteMaster);
        }
                
    }

    In the FeatureDeactivated method, these features are removed as well. Of course you can add or check for any other features here that you would like to add, such as the Enterprise Features.

    Insights Enabler

    Next up is to create the libraries and lists. Just add a new Empty Element SPI to the project and the lists as follows:

    <ListInstance Title="$Resources:ppsma,Onet_BICenter_Title"
                  Description="$Resources:ppsma,Onet_BICenter_Description"
                  TemplateType="450"
                  Url="Lists/PerformancePoint Content"
                  FeatureId="481333E1-A246-4d89-AFAB-D18C6FE344CE"
                  QuickLaunchUrl="$Resources:core,lists_Folder;/PerformancePoint Content/AllItems.aspx"
                  OnQuickLaunch="TRUE"/>
    <ListInstance Title="$Resources:ppsma,Onet_BIDataConnections_Title"
                  Description="$Resources:ppsma,Onet_BIDataConnections_Description"
                  TemplateType="470"
                  Url="Data Connections for PerformancePoint"
                  FeatureId="26676156-91A0-49F7-87AA-37B1D5F0C4D0"
                  OnQuickLaunch="TRUE"/>
    <ListInstance Title="$Resources:ppsma,Onet_BIDashboards_Title"
                  Description="$Resources:ppsma,Onet_BIDashboards_Description"
                  TemplateType="480"
                  Url="Dashboards"
                  FeatureId="F979E4DC-1852-4F26-AB92-D1B2A190AFC9"
                  OnQuickLaunch="TRUE"/>

    Insight list and librariesThis CAML is almost a copy of what is in the BI Center site definition, with only modifications so that the correct elements and attributes are used (ListInstance instead of List etc).

    Just hit F5 and watch it build and deploy beautifully. You can see the PerformancePoint lists and libraries in the Quick Launch. Also if you inspect the lists you can see that the correct content types are there.

    Adding the Dashboard Designer

    In order to utilize this fully we need to use the PerformancePoint Dashboard Designer. In the BI-Center template this application could be accessed through a button on one of the publishing pages that was added by default - not a nice solution.

    Instead we would like to have this one in the Site Actions menu, or any other suitable location. Site Actions is where I think it belongs. Let's add it there.

    Add a new Empty Element SPI and in that elements.xml add a CustomAction as follows:

    <CustomAction Id="LaunchPPSDD"
                  Location="Microsoft.SharePoint.StandardMenu"
                  GroupId="SiteActions"
                  Title="Dashboard Designer"
                  Description="Launch PerformancePoint Dashboard Designer"
                  ImageUrl="/_layouts/images/PPSSiteTemplateRun.png"
                  >
      <UrlAction Url="javascript:
    var a = _spPageContextInfo.siteServerRelativeUrl.toLowerCase();
    var b = _spPageContextInfo.webServerRelativeUrl.toLowerCase();
    var c = location.protocol + '//' + location.host + a;
    var d = b.replace(a,'');
    location.href = b + '/_layouts/ppswebparts/designerredirect.aspx' + '?SiteCollection=' + c + '&SiteLocation=' + d;"/>
    </CustomAction>

    The CustomAction uses the default Dashboard Designer image and contains a UrlAction with a JavaScript. This JavaScript launches the Dashboard Designer with the correct Site Collection and Site.

    Dashboard Designer CustomAction

    Deploy your solution once again and create your dashboards - without the BI-Center.

    Team BI Center

  • Understanding folders and namespaces in Visual Studio 2010 SharePoint Solutions, Packages and Features - part 2

    Tags: Visual Studio, SharePoint 2010

    This is a follow-up post to the Understanding folders and namespaces in Visual Studio 2010 SharePoint Solutions, Packages and Features (probably my longest blog post title, except this one...). In that post I discussed how folders and namespaces are handled in Visual Studio 2010 SharePoint projects. I will continue to show some details and tips on how you can affect the outcome of your project/packages.

    Long feature folder names

    As the previous post showed the features generated by Visual Studio ends up as a subfolder in the {SharePoint Root}\TEMPLATE\FEATURES folder. The feature folder will get the name as the concatenation of the project and the feature - which possibly can be quite long.

    Autogenerated feature name

    In the image above the project is called Wictor.Customer.Intranet.Services and the feature IntranetServicesWebParts. There is a good reason to have these auto generated names; it will avoid collisions of features. But if you are in control of the target farm you might consider having shorter names of your feature folders. This is easily done using Visual Studio; Deployment PathOpen up the feature in the Feature Designer and select the Properties tool window. (Note you cannot right-click the feature(s) node in the Solution Explorer and select Properties - that will just give you the properties of the Visual Studio feature file.) If you take a look at the Deployment Path property you will see that it has a default value of:

    $SharePoint.Project.FileNameWithoutExtension$_$SharePoint.Feature.FileNameWithoutExtension$

    As you can see it uses the Visual Studio replaceable parameters to generate the feature folder name. Just edit this to something that fits your "style of coding". It can be a combination of strings and replaceable parameters. For instance this:

    Intranet_$SharePoint.Feature.FileNameWithoutExtension$

    will generate a feature folder like this:

    Optimized feature folder name

    Just remember that it is a reason that the default value of the feature folder name is a combo of the project and feature names.

    Project Assemblies

    By default all SharePoint projects in Visual Studio generates an assembly which is registered in the GAC when deployed. This is done even if we don't write a single line of compiled code. SharePoint allows you to do really neat stuff using only a declarative approach - such as adding content types, list templates, list instances etc. For these projects it is totally unnecessary to install an assembly in the GAC. Fortunately Visual Studio allows you to configure your project so no assembly is generated or rather included in the WSP package (an assembly will still be compiled and created but not deployed with the package).

    If you have a fully declarative package and do not want to add an "empty" assembly to the GAC then you go to the Properties of the project (right-click the project node in the Solution Explorer for instance) and set the value of the Include Assembly In Package property to False.

    No, I don't want any assembly this time...

    Now when you package your solution no assembly will be created and you can deploy your solution using PowerShell without the -GACDeployment argument.

    That's all for today - have a great weekend!

  • 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?!

  • 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.

  • Local SharePoint 2010 development on Windows 7 - awesome experience

    Tags: Visual Studio, SQL Server, Windows Vista, Windows 7, SharePoint 2010

    I thought I should share my experience on working with SharePoint 2010 development on Windows 7. My previous posts on installing SharePoint 2007 on Vista and Windows 7 are posts that are quite popular. The downside with the “old” SharePoint version is that it was not officially supported to install it on a client machine, but SharePoint 2010 is supported for installation on Windows 7 and Windows Vista SP1 for development purposes.

    There are many opinions on having SharePoint 2010 installed on your client OS. Some thinks it is despicable, but I think it is great and I’ve used local installations for years now. It’s perfect for rapid development, testing and demos. In seconds you can spin up a site and show some basic stuff for a client. Of course I use virtualization when testing my final bits etc.

    Benefits and drawbacks

    Having a local installation have several benefits:

    • You are running on the metal – i.e. no virtualization layer
    • Speed!
    • If you don’t have more than 4GB RAM then virtualization will be really slow
    • Visual Studio 2010 heavily uses WPF which requires a lot of your GPU. The virtualization layer will degrade the WPF performance
    • You don’t need to spin up and shut down VMs
    • Saves you a lot of disk space – one VM requires at least 20GB

    Of course there are drawbacks. I would never go from developing on a local installation to production. Always test your code on a server OS!

    SharePoint Foundation 2010 on Windows 7

    I have installed SharePoint Foundation 2010 on my Windows 7 machine. I did not go for a full SharePoint Server installation. Most of the development can be done towards SPF and it makes a minimal impact on my client OS. But perhaps I go for a full SPS 2010 install once we have the final bits of it in June.

    MSDN contains instructions on how to install SharePoint 2010 on a client OS, you need to extract the setup files and make some changes to the setup configuration file. With SQL Server Development Edition installed on my machine I installed a Server Farm, i.e. not the Standalone configuration. I also used domain accounts when I installed it, which required me to be connected to the domain during installation.

    After the installation I’ve changed all SharePoint Services and SQL Services to be manually started to save some boot time. Emmanuel Bergerat has a great post on how to create Stop and Go scripts with PowerShell so that you quickly can start and stop all services. Starting these services and warming up my sites takes about 2-3 seconds on my machine equipped with an SSD (best gadget buy of 2010!)

    Visual Studio 2010 RC and Team Foundation 2010 Basic

    I use Visual Studio 2010 in combination with a Team Foundation Server 2010 Basic installation on my local machine. Using a local install of TFS is something I really recommend – never loose any of your local projects or files.

    Visual Studio uses the GPU a lot so you will certainly have a better experience running without a virtualization layer. F5 debugging is no pain, it just takes a second to compile, package, deploy and start Internet Explorer.

    Summary

    If you have not tried to install SharePoint Foundation 2010 on your Windows 7 then stop reading right now and do it! It will increase your productivity immediately. The experience is awesome and together with RC of Visual Studio 2010 it’s just amazing.

AWS Tracker

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