Another Tip if Visual Studio Times Out Trying to Deploy Your App in SharePoint 2013

I’ve had this happen to me, seemingly randomly, a number of times before.  You open Visual Studio and create a new SharePoint App.  You go through the wizard and then hit F5 to run, deploy and debug your app.  Something happens along the way though…you watch the output window and it just keeps counting time while it’s trying to deploy your app.  A few seconds, becomes a few minutes, which becomes several minutes, and then finally it just quits and says sorry, there was a deployment error.  Now no more walking away, looking at the sky and shouting “SERENITY NOW” friends – instead, here’s a tip that will hopefully help you.

When I had this happen to me (again) today, I changed the SharePoint site collection to which I was deploying the app to one I had successfully deployed before.  Sure enough, it worked like a champ.  Hmm, that got me to wondering.  Rather than looking at the whole side loading apps feature (which you really should not try and use as a work-around), I went to the problematic site collection and just went into the appregnew.aspx page (i.e. https://yourSiteCollection/_layouts/15/appregnew.aspx).  I generated a new client ID in there and registered my app, then I took that client ID and pasted it into my appmanifest.xml and web.config file.  I tried deploying to that site collection again and – voila! – sure as I’m the master of my own domain, the app deployed successfully and started running.

I’ve heard of many other folks hitting this issue…this is nearly as frustrating as those who can take the reservation, but can’t hold the reservation, so hopefully this will buy you some peace and happiness.

Your First SharePoint 2013 and Visual Studio 2012 Development Tip – the Old 32-Bit Process Error

Here’s your first development tip as you start cranking out SharePoint 2013 solutions using Visual Studio 2012.  An old an really annoying problem in Visual Studio 2010 when building SharePoint apps is that it defaulted to creating x86 applications.  The problem from a SharePoint perspective is that it gave you this incredibly useless “file not found” error message.  Awesome, eh??  🙂  

In Visual Studio 2012 the experience is somewhat better, but still needs a little shove to get all the way there.  By default now it creates winform projects that use .NET 4.5 (which is good) and which use Any CPU (which is good).  Unfortunately it also has a checkbox that says “Prefer 32-bit” which is checked by default (which is not good).  The saving grace here is that we have at least dramatically improved the error message now – it tells you that you are running a 32-bit process and you need a 64-bit process to load your SharePoint assembly.  The net of this little post is just to go and find that checkbox on the application property pages and uncheck it before you start running your code.

Packaging A SharePoint 2010 Custom Claims Provider in a Visual Studio 2010 SharePoint Project

For those of you who have been developing solutions for SharePoint 2010 with Visual Studio 2010, you may have noticed a slight packaging peculiarity when it comes to custom claims providers.  In Visual Studio 2010 you can create a new feature and you can easily add a feature event receiver to it by just right-clicking on the feature and selecting the Add Event Receiver menu.  That’s nice because it’s very easy and productive to get working on the coding for your solution rather than the configuration.  The disconnect comes in because the event receiver it adds by default inherits from SPFeatureReceiver.  As I’m sure you all know, the event receiver used to register a custom claims provider must inherit from SPClaimProviderFeatureReceiver (  In addition, the built in SharePoint smarts in Visual Studio don’t lend itself to a really intuitive way to just add a class to a SharePoint 2010 project and then have it associated with a feature.  There is however a fairly easy and slick way around this.
I went down this path a while ago when I was beginning with my usual starting point – I had a custom claims provider I had written and corresponding feature receiver to install it.  These two classes were part of a single project.  I decided that I really wanted to make the new feature packaging goo in Visual Studio 2010 work for me, so here’s how I did it.

1.       Complete your first run at your custom claim provider project and corresponding event receiver for registration, then compile it.  You want to look at the compiled assembly and get the strong name for the assembly as well as the class name for the event receiver.

2.       Add a new project to your solution, and base it on a SharePoint 2010 “Empty SharePoint Project” template.  Configure the project to be deployed as a farm solution.

3.       Right click on the Features node in the project and select Add Feature.  Your feature should be scoped to Farm and should auto activate.  Otherwise, configure the feature properties as appropriate for what you are trying to do.  Here is the important point – configure these two properties on the feature (in the Visual Studio Properties window) as described:

a.       Receiver Assembly:  put in the strong name to your assembly described in step #1, for example MyClaimProvider.ClaimTest, Version=, Culture=neutral, PublicKeyToken=edb00fee02fa0701

b.      Receiver Class:  put in the name of the class that you wrote your custom claims provider in step #1, for example MyClaimProvider.ClaimTest.MyClaimsFeatureReceiver

4.       Add your compiled custom claims provider assembly to the list of assemblies your packaging solution is going to deploy.  To do this, double-click on the Package.package node in the Visual Studio packaging project.  Click on the Advanced tab.  Click on the Add button, then the Add Existing Assembly menu.  Find the correct location for your compiled custom claims provider assembly, and leave the Deployment Target: GlobalAssemblyCache selected (it is by default).  Click the OK button to save your changes and then you can close the Package properties window.  One thing to note here – I usually just create a folder in my packaging project where I copy my compiled assemblies from other projects that I want to be distributed with the solution.  When I configure the additional assemblies in the Package, I just select from the folder in my packaging project.  In my other projects, I have a post-build script that automatically copies the compiled assembly into this assembly folder in my packaging project.  It’s a simple one line of code post-build that copies the assembly whether it’s a debug or release build so I don’t need to remember to do it myself each time.  It looks like this: 

copy “$(TargetPath)” ..\..\..\MyPackagingProject\GacFiles /Y
Your package is now complete.  You just need to compile the package project and then select the Package menu from the right-click menu for the project.  You’ll end up with a WSP file that you can then distribute and have it automatically roll out your custom claims provider.

Intellisense for Properties on ASP.NET Custom Server Controls

NOTE:  The solution described below is only necessary if your web page and custom control are in the same project.

I had this really not fun time this week blowing a couple of hours on something that should have been zero impact so I thought I’d share here.  I wrote a custom ASP.NET server control and then added to an ASPX page with the Register tag, and then added a tag for my control.  I then went to set one of the properties of the control in the attributes of the control tag in the ASPX, the way everyone is used to doing.  The really frustrating thing is that it wasn’t showing any of my custom properties.  After messing around with it for a couple of hours and getting no where, I finally realized that I had to close Visual Studio 2010 completely, then reopen it to see the properties I had added.  Yes, don’t be confused when looking at the calendar, it really is 2010.

So to get custom properties to show up in the ASPX Intellisense you need to:

  • Use properties that are Read / Write
  • Recompile your control and register in the GAC or place in the BIN of your ASP.NET app
  • Close Visual Studio
  • Reopen Visual Studio
  • Junk starts working

Hope this saves someone some time.