Visual Studio Tip #2: Run 64-bit version of PowerShell in Post-Build

Whether you are trying to achieve Continuous Integration, Automated Unit Testing or any other scenarios, it might be very beneficial to run PowerShell scripts automatically from Visual Studio after certain actions (such as Deploy or Build).

One problem I had was with the version of PowerShell that would be called from Visual Studio 2010: 32-bit or 64-bit. If you need to use SharePoint DLL's, you need to run the 64-bit version of PowerShell.

It won't work using "%WINDIR%\system32\ WindowsPowerShell \v1.0\powershell.exe", you'll get an error using the 64-bit DLLs, because the PowerShell console that is opened is the 32-bit version.

In order to call the 64-bit version of PowerShell, you must use this path: %WINDIR%\sysNative\WindowsPowerShell\v1.0\powershell.exe.

SharePoint 2010 Tip #8: Site Collection URL without "/sites"

It is common to have people asking why new Site Collections have to be in "/sites", or any other common location, and not in the root (http://hostname/<sitecollection>). Some people find it annoying, or not appropriate.

It doesn't have to be that way, we can have our http://hostname/<sitecollection>. And we don't need any URL rewriting or any other complex solution, just use the OOTB options correctly!

We will have a quick dive into the Central Administration, in Application Management > Manage web applications. Select a Web Application and click "Managed Paths" in the ribbon. The reason why the only option when creating a new Site Collection is "/sites" is due to the configuration there.

The default configuration is, as follows:

• (root) - Explicit inclusion
• sites - Wildcard inclusion

What does this mean? It means that we can have one Site Collection in the root (/) and multiple inside sites (/sites/*). That's exactly what is happening. When you create your root Site Collection you put into the root URL ("/") and when creating a new Site Collection you only have the /sites option.

The explicit inclusion type allows you to create a single Site Collection in the specific specified URL (/<url>), while the wildcard inclusion allows you to create multiple sites inside the specified URL (/<url>/*), but not in the base URL itself.

The reason for this is simple, if you had a Site Collection in that level and multiple Site Collections beneath it, IIS/SharePoint would not know (in a simple way) where to route when accessing a site in /<url>/*. Would it be a subsite in the root Site Collection or a Site Collection within it? That's why trying something like making the (root) a wildcard inclusion will not work if you plan having a Site Collection in the root as well. If you don't (only Site Collections in /*), that would actually work well.

Then, going back to our problem, how to create a specific location for our Site Collection (http://hostname/<sitecollection>)?

Just add a new managed path, enter the URL you want (<sitecollection>) and choose "Explicit inclusion" as type. The next time you create a new Site Collection, you will have this path available to you!

Once you use it in a Site Collection, it will obviously not be available in the creation of further Site Collections, which means you must configure a managed path for each Site Collection you want to place as http://hostname/<sitecollection>, which actually makes total sense.

When creating your managed paths, you should always click "Check URL" to make sure no subsite is created in that location. If it does, you will actually be unable to enter that subsite while the managed path is there, as SharePoint will always try to redirect you to the Site Collection using that path. If you haven't created the Site Collection, you will get a HTTP 404 Not Found, you will still not get redirected to the subsite. Deleting the managed path will get everything back to normal.

On the other hand, after creating a managed path and when creating a subsite in that location in the root Site Collection, you will get the following error:

Error
"<url>" cannot be used as a site name. Site names cannot contain certain reserved words and cannot begin with an underscore. Please enter a different name.

Site name actually refers to Site URL name, and not Site Title (one of those funny SharePoint error messages).

SharePoint checks if the subsite URL collides with any of the managed paths and actually enforce that no subsite is created there.

Visual Studio Tip #1: 'View Designer' option disappeared

This happened to me while building a SharePoint workflow.

I created an initiation form with the same name as the workflow, which generates a compilation error: the workflow class will be the same as the code behind in the initiation form. Changing it solves the compilation issue, but you competely lose the ability to view your workflow in Designer mode.

This happens because changes are performed on the .csproj when you add the initiation form, stating the class SubType is ASPXCodeBehing. When you rename the initiation form, new entries are created, but the old one remains as ASPXCodeBehind, instead of returning to the initial value, when you created the workflow.

Re-opening Visual Studio may or may not solve it.

You can go to the .csproj and make sure your class SubType is set to Component, and not Code or ASPXCodeBehind.

Thoughts on the Microsoft Approach

To me, Microsoft Products have always had some common ground and guiding light. Microsoft's motto over all these years has been all about having products with a very user friendly interface and products that provide very quick and direct advantages, with little or no development time.

So...why aren't all products like that? Well, nothing is perfect, so sometimes having things that simple, have disadvantages. Working hard to solve the top 80% scenarios, will usually leave the other 20% in bad shape.

What does that mean in practice? Basically, you can give your customers great value for money if their scenario fits the scenario Microsoft predicted. If the configurations allow you to configure that simple thing they asked you to change. Otherwise, you may be in trouble. Changing that small thing may be close to impossible sometimes. You may need to do your own custom development from scratch, while having something that close OOTB.

So, in relation to SharePoint, how does that affect a Developer or Consultant?

In my own view of things, a SharePoint Developer should not be a standard Developer. For that matter, in almost all the platforms I have worked with, the same principle applies.
A SharePoint Developer shouldn't be focusing only on the code itself or in the best way to deploy SharePoint artifacts. Its job should be to know the platform very well, and first of all, knowing all of the platform's abilities and OOTB components.

One would say: if Microsoft is pushing SharePoint in so many business areas and to serve so many purposes, isn't it impossible to know everything about the platform?

In my opinion, yes. To become a 'de facto' expert in some of the areas explored in SharePoint, you will need several years of experience, and every day you may still be learning something new. That's just the way it is. But the goal here is to understand where your efforts should be placed. And in my opinion, you should strive to understand the full SharePoint experience.

If you are just developing custom Web Parts, you will also gain a lot if you understand how OOTB SharePoint Web Parts behave and how you can leverage them. You shouldn't have to rely on the Functional Consultant to tell you what's there OOTB to solve the problem you have in hands. You will provide more and better value by knowing it yourself and being able to take advantage of everything that's already there.

This may seem intuitive, but it is hardly applied on the real world. The example I gave here is about a SharePoint Developer knowing the OOTB platform, but also applies even within each role's responsibilities. For instance, SharePoint Functional Consultants who have been largely involved in Collaboration projects will gain huge value if they understand and know what's there in terms of Web Content Management and Enterprise Content Management. Because when you deploy a SharePoint farm with a Standard or Enterprise licence, you are offering you customer a very wide range of functionality that can be used for multiple purposes.

The best example I have on this is the Publishing Feature. All the Collaboration projects I have worked in so far, with a Standard/Enterprise licence, I have recommended having that feature enabled. The functionality it provides OOTB is easy to understand and, even if Pages are not the core of the project, this feature provides a number of advantages that will always be very useful.

Now, going back to the SharePoint Developer. If he focus more on the platform and less on code, what will he lose?

He will obviously be a less experienced coder than someone who develops 24/7 using C#, Java or Ruby on Rails. Maybe his patterns and best practices knowledge won't be as deep as those guys. He should still invest on that, but not as a "full time" thing. Balance both worlds is the best approach, at least if he is committed to developing for platforms. There is a high number of SharePoint projects that involve zero coding and a number of them where you'll end up with just 3 or 4 pages of code.

Knowing where to place yourself to maximize the value you provide is key.

SharePoint 2010 Tip #7: Creating Site Collection in new Content Database

Another quick but efficient tip, this time for SharePoint 2010: creating a Site Collection in a different or new Content Database.

One would have guessed that would be very simple. Maybe you'd have a choice in the Site Collection creation interface. And in that choice, you'd be able to choose which Content Database to use, or even creating a new one. But no, there is no option whatsoever in the Site Collection creation interface regarding Content Databases.

Well, although it's not that intuitive, it is easy. Here's what you need to do.

First, you need to create the new Content Database. You can do it in the Central Administration interface for that purpose, very simple and no caveats there.

After having the target Content Database created, before you create your Site Collection, you need to get all the other Content Databases in that Web Application status to Offline, leaving your new Content Database as the only one with status set to Ready.

Now, just create the Site Collection and it will use your Content Database, as it is the only one with Ready status.

Don't forget to re-set all the other Content Databases status to Ready in the end.

Windows Server 2008 Tip #1: IE without restrictions

This is a very quick tip for Windows Server 2008, but very useful.

Ever had to download some sort of software to a server, but the download page had some sort of asynchronous behaviour with JavaScript? Or maybe the page had something more going on, that would just not work while using it in the server's Internet Explorer?

It happened to me recently, I wanted to download Microsoft's Productivity Hub SP1 and install it in a SharePoint farm. The server has a very good Internet connection and I was logged remotely (in a slow connection), so the best way to do it would always be downloading the files locally in the server (about 2GB).

The problem: I needed to login with my Live account to be able to download the files. Adding those sites to the Trusted Sites (they are all Microsoft sites) actually solved the login issue. But to download these files, I also had to fill in some register information, as these are not directly downloadable. That register page uses some asynchronous code that, even having the site as Trusted, would not run.

The solution is quite simple: go to the Server Manager and disable Internet Explorer Enhanced Security Configuration (IE ESC) for Administrators. Everything will work after disabling that. Some printscreens below.

References: here

SharePoint 2010 Tip #6: Saving Document Templates in Library

If you are saving your Document Templates in a SharePoint library, don't forget to load the appropriate Content Type to that Library, otherwise your Document Template will be attached to the "Document" Content Type, which only has the "Title" metadata field.

If you don't, your Document Template will lose the association with your Content Type. When you create a new document using that Document Type, the Information Panel will not load your Content Type and any QuickPart you have configured will not work well.

The error will only be fixed once the user tries to save the Document to the Library, and only in the case you have mandatory fields in your Content Type, as SharePoint detects there are missing mandatory metadata fields and block you from saving.

Use jQuery in Chrome Console

Since Chrome in gaining momentum (and Firefox losing it) I though I'd start using it in my new laptop and don't even download FF.

I have been quite happy so far, but I just discovered a caveat: if you are using the Console to quickly test some HTML / JavaScript / jQuery / CSS, then be aware that the Chrome Console will replace jQuery's $ function with it's own, that is actually an alias to getDocumentById.

To quickly check it, just use jQuery===$ and see the output. Or if you just enter $, Chrome should have changed that function to the following:

function () {
     return document.getElementById.apply(document, arguments)
}

That means if you select an id it would actually return what you expect, but everything else will fail. So just use jQuery() for your quick test in the Console, and that's it!

EDIT: this bug is already fixed (here), so the problem must be another one. In Twitter, @fbatista answered me with the most probable option: a misplaced $.noConflict()!

Search Requirements Gathering

Just stumbled upon a great presentation about Search Requirements Gathering, from Michal Pisarek (SharePoint MVP). You can see the slides here.

The first thing is to acknowledge the challenge: search is perceived as something that works out of the box and magically presents users with the most amazing results. Little or no time is expected to be spent analysing the quality of results and getting a governance plan together (yes, for search!). Also, in most projects, search requirements are pretty much reduced to knowing which Content Sources need to be in place.

To me, the most important thing is to focus on the value it can deliver. Specific business driven actions that are performed within the organization on a daily basis, that can be improved using SharePoint Search. Attainable goals.

Here are some interesting statistics (Source: Google / IDC):
Each worker currently spends, on average, 9.5 hours per week searching for information. And 3 hours a week recreating content that already exists!
According to the same study, having a high-quality enterprise search implementation will reduce the search time by 50%. That's more than 4 hours a week, or half a day!

How can you achieve these results? You must know what are users searching for and the perceived time they spend doing it. You must understand what is used on a daily basis and on a monthly basis. What is working fine and what is not working at all.
That's the most important step. Then, you have the information you need to build a search configuration focused on their daily needs that can massively improve their searching ability, by filling in the gaps and giving them an integrated system where they can find what they are looking for.

There is also additional value you can push with search. In a successful implementation, users will better understand the importance of metadata, so they may take extra care when categorizing a document. Having the people search box on the right hand side of the search page, can help them realize the value of filling in their "Ask me about" data. And going into someone's profile, may show them the utility of the Organization Browser.

It is definitely a snowball.

Providing a major initial benefit for users working with the SharePoint platform (Search), can help gain buy-in from the users and you can later take advantage in other areas that, by themselves, wouldn't be powerful enough to bring users to the platform.

Another interesting read on this: Using Search Analytics (presentation).

Humility and Code

What a great article by Phil Factor, in today's SQL Server Central editorial (find it here).

"Don't criticize code".

We all know how time constraints work. We all wished we just had all the time needed to make the best of a tricky problem, project or set of business requirements. But sometimes we don't. Sometimes there's no available time frame, things just have to work, from a high-level perspective. What happens beneath it (read: code), stays there.

So, when you are evaluating some previous work on a legacy system, it is important to be aware of this.
Coming in and just pointing out what's wrong is easy. Bashing is easy. Destroying is easy.
Making it better, or getting it right the first time, in similar situations...not so much. Being constructive, taking a positive approach and understanding constraints is a sign of experience and maturity. Also, quite possibly, a major key factor in enabling good flows of work, organizational adoption and, overall, getting better results.