ISQ #7: The case of uncontrollable InitializeControl

I occasionally see tweets that Visual Studio 2012 is the best IDE. They have not seen IntelliJ. I was a fan of Eclipse for a long time and after working on IntelliJ, its hard to go back. Yeah.. you’ve heard that so many times. Visual Studio 2012 doesnt come close to that, because IntelliJ works with you, never against you. There are many things plain frustrating with VS2012 (an yelling all caps menu, lousy gray theme, even lousier icons and text and so on), the rants are all over the net, so I will skip them.

Working on a SharePoint 2010 project with Visual Studio 2012, you might have seen the error “The name InitializeControl does not exist in the current context”.

The problem happens when using sandboxed VisualWebPart, lets say DisplayWebPart.ascx, which should generate a ascx.cs file and a ascx.g.cs file. But a major bug is that the g.cs file is not often generated properly and even if you force regenerate (by manually deleting files from File Explorer), it creates DisplayWebPart1.ascx.g.cs (a mysterious 1 being appended the file name). Well try consolidating that with the TFS, if you still happen to use that archaic software as your version control system. There are several solutions on msdn, stackoverflow etc, but none really worked for me. After a lot of scratching around, I found a way that consistently generates the g.cs file, correctly.

Here are the steps:

  1. Ensure the Project’s, not the Solution’s, “Site URL” is set to a valid SharePoint URL. (Impressive dependency, to regenerate your designer code locally, you need to have a valid working reachable SharePoint url)
  2. Right click on .ascx file, select Properties, and update the property “Custom Tool” to “SharePointWebPartCodeGenerator”.
  3. Right click on the .ascx file and click Run Custom Tool. At this point, if the “DisplayWebPart1.ascx.g.cs” is regenerated, your frustration is acceptable.
  4. Open the project.csproj file in Notepad++ or other editor, find the line DisplayWebPart1.ascx.g.cs
    You should see something like this:
    <Content Include=”DisplayWebPart\DisplayWebPart.ascx”>
    <Generator>SharePointWebPartCodeGenerator</Generator><LastGenOutput>DisplayWebPart1.ascx.g.cs</LastGenOutput>
    </Content>
  5. Change the LastGenOutput value to DisplayWebPart.ascx.g.cs
  6. Go back to Visual Studio 2012 and it asks to Reload the project (or Discard). 
  7. Reload the project
  8. Right click on .ascx file and Run Custom Tool again
  9. Voila, the 1 is gone and the file should be now called DisplayWebPart.ascx.g.cs.

So whats the moral of the story? Inconspicuosness is directly proportional to frustration. Like having a valid working reachable Site Url to regenerate a local designer code.

Inconspicuous SharePoint Quirks #1

Mystery of the Unimportable WebPart

So Voltaire said “God protect me from my friends, I will take care of my enemies”. If there was a SharePoint God, I would probably pray to him “Protect me from the inconspicuous quirks, I will blogoogle the rest”.

So I have a wsp with a webparts feature. After deploying a wsp to the dev server, I added a webpart to a page which showed me a charming message “Cannot import webpart”. Call me schizophrenic but a voice inside me told that dont waste time at the logs, they are not going to help. This was working fine in my local vm, but trouble-some in dev server. So what’s wrong? After a miss-adventrous chasing of dead-ends, cul-de-sacs, and no-outlets finally figured a method that works consistently.

  1. First of all, ensure that the elements.xml, SharePointProjectItem.spdata, the .webpart file, feature.xml, package.xml are all correct. Make sure the Group is correct too, or else your users will not find the expected webpart.
  2. If your webpart is extending from Microsoft.SharePoint.WebPartPages.WebPart, you must use the wss/v2 schema, ie the webpart should have a .dwp extension. The newer .webpart extension/v3 schema works only for ASP.Net webparts
  3. After deploying the wsp, check if the web.config has the correct SafeControl entry with correct version of assemblies. Also check the GAC for correct version.
  4. Goto http://server/_catalogs/wp/Forms/AllItems.aspx. This lists all the webparts in Web Part Gallery. See the Modified Time, is it the latest? If not, delete all the webparts. (You can use a simple powershell script for that).
  5. Now deactivate the webpart feature (Disable-SPFeature featureName)
  6. Again activate the webpart feature (Enable-SPFeature featureName)
  7. Check the Web Part Gallery, now all the webparts should be added.
  8. Try adding the webpart again and if it still says “Cannot import webpart”, pray to SPGod.

So why was it working on my local vm? Oh yeah. Turns that there is a bug in Visual Studio 2010 Deploy command which would not Activate the features automatically. So some time ago I had set it to “No-Activation” deployment configuration and I was activating the features via powershell. That powershell activation was taking for adding the webparts correctly to the web part gallery. On the dev server, I was assuming that the install-spsolution automatically refreshes the web part gallery too, but it does not.

It is well blogumented that webparts are not removed from the gallery upon uninstall-spsolution, but now I know it does not update the webparts  either using install-spsolution, yet the feature is blissfully activated. Cunningly symmetrically logical eh?