This one never gets old. Everytime we want to install SharePoint, we tend to continue to work on the server getting as much done as possible. And, everytime, we’re confronted with the inability to authenticate using Windows username and password and a browser on the web front end server.

You try so carefully to enter your DomainName\UserName and password exactly correctly and hit enter, enter, enter and you get a 401 or, worse, just a blank screen. As we’ve learned, what we’ve encountered is the dreaded anti-loopback monster.

Now, the ALM is a fine security measure on a server that you deploy and then spend the rest of your life as a SharePoint admin working from another workstation. It simply prevents authentication from the local machine using host headers other than the machine name. It’s detailed here on support.microsoft.com. Apparetly the threat is a “Reflection Attack” which reminds me of my mirror on the occasional Sunday morning before my shower.

Essentially, we’re creating a two registry keys:

1. DisableLoopbackCheck dword registry key with a decimal value of 1 in the HKLM\SYSTEM\CurrrentControlSet\Control\Lsa hive. 
2. DisableStrictNameChecking dword registry key with a decimal value of 1 in the HKLM\SYSTEM\CurrrentControlSet\Services\
   LanManServer\Parameters hive.

Once we restart, we should be able to access our sites locally using the propery credentials. Of course, this is a “must have” kind of thing if you’re building a development box where you’ll be accessing the WFE from the local machine in Visual Studio.

hth
-robot

Sometime, you want to give your user a link to create a document in a library somewhere using a document template tied to one of the library’s content types.

Our new best friends at SharePointKings.com gave us a head start on figuring it out. I just had to pull out my ASCII character map to decode all the escape characters and found they mostly didn’t matter.  So, using our handy dandy content editor web part, we can drop this code in place to cross this one off our list:

<A onfocus="OnLink(this)" HREF="XXX Item 1 XXX" onclick=
"createNewDocumentWithProgID('XXX ITEM 2 XXX', 'XXX ITEM 3 XXX',
'SharePoint.OpenDocuments', false)">Create Instance of Content
Type in Specified Library</A>

Just replace my place holders as follows:

“XXX ITEM 1 XXX” = Relative path to template in \Site\Subsite\library\forms\content type\ folder, i.e.

"/SiteDirectory/My%20Site/My%20Library/Forms/My%20Content%20Type/
Template%20File%20Name.docx"

 I’m using %20 for blank spaces. You can browse to the folder in Explorer view to be sure you have it right. Just swap the \s in favor of /s

‘XXX ITEM 2 XXX’ = Full path to template in \content type folder. In my example above, that would be:

'http://MyDomain.com//SiteDirectory/My%20Site/My%20Library/
Forms/My%20Content%20Type/Template%20File%20Name.docx'

Use single quotes.

‘XXX ITEM 3 XXX’ = Full path to host library. In my example above, that would be:

'http://MyDomain.com//SiteDirectory/My%20Site/My%20Library'.

Again use single quotes.

I’m not sure what the OnFocus= does for us and I can’t testify to the efficacy of the relative vs. full paths but this format does the trick for me.

hth
-robot

Have you ever uttered an obscenity when you tried to build a web part for SharePoint 2007? How about for SharePoint 2003? Wasn’t that just ridiculous? Well on first review, your vocabulary may be taking a turn for the better; This really is easy.

The one thing that hasn’t gotten any better is the propensity for the providers of “How-To” guides at Microsoft to booger things up while we struggle with these new concepts.

For example, anybody that can make heads or tails out of this ought to work for the Franklin Mint. As I read it, the file names vary from step to step and the code includes the fancy left and right side quotation marks that blow up your .cs pages. So I went looking for another one.

Then I found this one that was much better but still has at least one “gotcha.” It seems that the author neglected to properly modify his name space in his sample code and that will blow up your build. This gives us a good chance to try to figure our what his or her  problem is.

Recall that we’re running SharePoint Foundation on Windows 7 x64 VM, per our recent posts, and that we’ve installed VS2010 from the 90 day trial download version.

First, like I said, the create\build\deploy steps are a snap. In VS 2010, it’s File | New | Project and under the C# projects, select the SharePoint 2010 node, select the Visual Web Part and click OK. One thing to think about is where you put the solution. In Windows 7, if you put it in the C:\Sample Web Parts folder, you’ll have to do a silly Run As Administrator tap dance later to delete it. I chose to create and use a folder under my user name folder next to My Documents and check the Create directory for solution option. Then click OK.

Then, you get one of the cool new parts, it asks you for the site where you want to deploy\debug your web part. I created a blank sample site and used it. My Deploy as a Sandboxed Solution option was greyed out; not sure what to make of that. I just clicked Finish.

So my solution gets built and I’ve got a bunch of files and since I didn’t change the name in the previous step, in Solution Explorer, I’ve got a VisualWebPart1 node. I see it have a VisualWebPart1UserControl.ascx file under it which has a VisualWebPart1UserControl.ascx.cs file under it which has a VisualWebPart1UserControl.ascx.design file under it. Pretty Deep, no?.

Okay, on the .ascx file, right click and select View Design. The design page and the tool box open. In the toolbox, find the TreeView control under the Navigation section (Very Visio-like toolbox) and drag one onto the design. When the treeview control is selected in the design pane, its properties will show up in the properties pane at the bottom right of the VS workspace. Find the ID property and set it to siteStructure and then click Save. So far, so good.

Then we have to code the .cs page to populate the tree when the page loads. The guy\gal that wrote the post (here‘s another link to it)  just gives us the code with a convenient Copy Code link. Click the link. Back in your project, right click the .ascx.cs file and select view code. Click in the code somewhere and press CTRL-A | CTRL-V.

Notice the red squiggleys in two palces, both under the word siteStructure? Believe me, these guys get paid way more than me so they ought to know better.

Here’s the problem. The dude\dudette was obviously on his way back to Seattle back from Burning Man when he wrote this and he had Bonneville on his mind and wrote that into his namespace. Now I probably don’t understand namespaces as well as some of you, but I know:

BonnevilleTestBed.Bonneville <>VisualWebPartProject1.VisualWebPart1

The left side of that equation is the namespace cited in the .cs code we copied from the guy’s article. In addition, the code tries to build a partial class called:

BonnevilleUserControl

The left side of that equation is the namespace cited in the .cs code we copied from the guy’s article. If you right click on the .ascx.designer.cs page and select View Code, you’ll see that what we really need is a namespace called VisualWebPartProject1.VisualWebPart1 and a partial class named VisualWebpart1UserControl.

Copy those names from the .designer.cs page to the .ascx.cs page overwriting the silly Bonneville stuff. The red squiggleys go away. Press f5.

My Sample site comes up and sits there like it’s a SharePoint site which, of course it is, but it’s not doing anything. But, I can select Edit Page from the Site Actions menu and click Add a Web Part. In the Categories picker on the left, I select Custom and there’s my VisualWebPart1. I select it and the click Add and then click the Stop Editing button on the ribbon.

Since I used a blank site, there’s nothing under my Sample Site node but, as I add lists, libraries and subsites, they fall into my tree view just fine.

Now all we need to do it build a solution we can add to our SharePoint sites for real, not just in our debugger mode.

There’s a great expository on the process here written by our new best friend, Eric, at BinaryWave.com. He explains the advantages of the new process and an introduction to the steps we’ll take to deploy our new web part to a production farm.

Eric brings up a couple of great, new points, the first of which is conflict resolution. These are issues that arise when, for example, I deploy MyWebPart as a feature in a site where you’ve already deployed your MyWebPart. Conflict, Ouch! Let’s ignore this for now with a promise to explore these conflict resolution properties later.

Second, Eric tells us we’re really dealing with SPI’s (SharePoint Items.) These are the components that will be mashed into a solution for deployment. In our case we have one, VisualWebPart1. Eric tells us:

By default, all SPI’s in the project which are included in a Feature, along with any mapped folders, will be automatically added to the package.

That should work for us now since what we want is a package with our web part in it that we can add to our production environment. Where we’re headed is a file called package.package. See why I love this job? As we may already know, the steps are to bundle our SPI’s into a package, deploy the package as a solution on our target location and activate the features that bring our SPI’s to life while, at the same time, avoiding any conflict nastiness.

At this point Eric strays off into other objectives as we go looking for someone more on point, like our new best friend Belajar, here. He says right-click on our project name and select Package. I get a status bar indication that Package Succeeded and I get a VisualWebPartProject1.wsp in my project’s bin\debug folder.

So with the .wsp in hand, we need only to load it into our production portal. The best source for this info is our new best friend, ICC, who feeds us, here, the PowerShell routines that get this done for us.

I do the add-spsolution and that works fine.

Then, I try the install-spsolution and I get this silly error:

PS> install-spsolution -identity visualwebpartproject1.wsp -webapplication http://Jeffery -GACDeployment
Install-SPSolution : Admin SVC must be running in order to create deployment timer job.

That is where we go look at our Windows services and find the SharePoint 2010 Administration Service and start it. I recall setting it to Manual Start previously to conserve resources on the “Production” box. Then I have to go look in Central Administration to find the timer job that started but never ended. It’s in the list under Central Admin | Monitoring | Check job status. Now the status page is nice but with the way it pages, it’s kind of clumsy so I click on Job Definitions and found the VisualWebPartProject1 job and opened it and selected Delete. Then I went back to PowerShell and ran my install again. When it returns a PS prompt, I know something worked.

So I create a web part page to add my new web part to and it’s not there. Rats.

This leads me to the Web Part Gallery. It’s not there either.  More Rats.

Now this part is tricky. Notice, on the Web Part Gallery, up on the ribbon, you get a Library Tools set with a Documents and a Library option. Clicking on Documents we get a New Document option. Click it Baby!

 At the very bottom of the list, there’s our VisualWebProject1.VisualWebPart1.VisualWebPart1 web part. Drop an X in the box and click Populate Gallery back at the top of the page. That takes us back to the gallery with our new web part sitting there with a little SharePoint New flag next to it.

Go back to the web part page and click on the Add Web Part link. In the Miscellaneous group, we get the VisualWebPart1 option. Select it and click Add. Click the red X to stop editing and reload the page.

That has got to be the prettiest web part I have ever seen.

This is also where we’ll start our “Yay, It’s Friday” celebration. Have you seen Hoops and Yoyo’s “I Don’t Care Friday” routine?

-robot