“The name ‘InitializeControl’ does not exist in the current context” - Visual Web Part (Sandboxed) bug and how to fix it

A while ago Microsoft provided us with Visual Studio 2010 SharePoint Power Tools – a set of productivity extensions for the Visual Studio 2010 SharePoint Developer Tools. One of the improvements shipped with the Power Tools is the Visual Web Part (Sandboxed) that – as the name says it – allows you to both benefit of the great design capabilities of Visual Web Part while still being able to deploy it to Sandbox. Unfortunately if your Sandboxed Visual Web Part will get too large things won’t be working as expected anymore.

Visual Web Part 101

One of the great things about Visual Web Parts is the simplicity of designing the UI. While in a regular Web Part you would have to code every single line of the UI, the Visual Web Part allows you to leverage the power of User Controls’ (ASCX) design surface to design the UI imperatively, what makes it very easy not only to design the UI but also to maintain in.

During the deployment process the User Control is being deployed to the {SharePoint Root}\TEMPLATE\CONTROLTEMPLATES folder. On runtime the Web Part loads the User Control and instantiates it and so the imperative UI becomes a part of the Web Part.

Visual Web Part (Sandboxed)

When working with Sandbox things look a little different. Sandboxed Solutions have no access to the file system and therefore cannot deploy any files, such as User Controls, to the SharePoint Root folder. Luckily, there are better alternatives for us than coding the UI in our custom Web Parts.

Last June Microsoft provided us with a great alternative to coding the UI - the Visual Web Part (Sandboxed). Provided as a part of the Visual Studio 2010 SharePoint Power Tools, the Sandboxed Visual Web Part is a great productivity extension every SharePoint developer should be familiar with. Just like its older brother, the Sandboxed Visual Web Part uses User Controls to imperatively design the UI. The biggest difference between those two Web Parts is that during the build process, the User Control of the Sandboxed Visual Web Part is being parsed and included in the assembly as a class. And so no trace of ASCX is to be found in the generated SharePoint Solution Package (WSP) and the Web Part can be deployed to Sandbox.

Sandboxed Visual Web Part offers you a great way to create custom Web Parts and become productive. Additional benefit that you get from using the Sandboxed Visual Web Part is the security: because you don’t need to load and instantiate the User Control on runtime the Sandboxed Visual Web Part requires less privileges. So even if your Solution won’t be deployed to Sandbox you should definitely consider using the Sandboxed Visual Web Part.

There is however one ‘however’…

The name ‘InitializeControl’ does not exist in the current context

Recently, while working with the Visual Web Part (Sandboxed), my fellow developer stumbled upon a weird issue. After implementing some UI in the Sandboxed Visual Web Part’s User Control, he got the following error while trying to build the project:

Surprisingly: the User Control’s designer file (.ascx.g.cs) was missing! What’s also surprising was that a newly added – empty – Visual Web Part (Sandboxed) didn’t give such error. So what was exactly going on?

After some research we found out that the error has to do with the length of the contents of the User Control. Once you exceed the limit of 8256 characters the User Controls won’t be parsed anymore. Compare the two images. With the contents length of 8256 characters the ascx.g.cs file is still present in the solution.

Once you add another character to the file and save it, the ascx.g.cs file will disappear and the familiar error will appear if you try to build the project.

So does this mean we have to slice UI into multiple controls in order to use the Sandboxed Visual Web Part?

Fix, the

The great news is, that we don’t have to do anything with our code! Last December Microsoft published Visual Studio 2010 Service Pack 1 Beta which fixes this issue. After you install this Service Pack, the limit issue is solved and you can proceed with designing rich and complex UIs for Sandboxed Visual Web Parts.

Big thanks to the Visual Studio team for fixing this bug!

Technorati Tags: SharePoint 2010,Visual Studio 2010