Localization of a SharePoint Visual Web Part - The name 'InitializeControl' does not exist in the current context - by Raphael Londner -

Status : 

  Fixed<br /><br />
		This item has been fixed in the current or upcoming version of this product.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.

Sign in
to vote
ID 776185 Comments
Status Closed Workarounds
Type Bug Repros 1
Opened 1/9/2013 5:11:03 PM
Access Restriction Public



I am running VS Ultimate 2012 11.0.51106.01 Update 1 with the SharePoint Developer Tools Preview 2.

I've been trying to build a localized SharePoint Visual Web Part but I am getting the infamous 'The name 'InitializeControl' does not exist in the current context' error when trying to reference a project resource file in the user control's ASCX source.

The ascx.g.cs file subsequently becomes blank and the project no longer compiles.

How can resource files be used inside an ASCX control with the new 2012 Visual Web Part?

Thanks in advance for your help,

Sign in to post a comment.
Posted by Deon [MSFT] on 4/29/2014 at 12:29 PM
Thank you for reporting this issue. This issue has been fixed in Visual Studio 2013. You can install a trial version of Visual Studio 2013 with the fix from: http://go.microsoft.com/?linkid=9832436
Posted by Iouri Simernitski - MSFT on 4/30/2013 at 6:11 PM
I uploaded a solution (LocalizedVisualWebPartToolsRTW.zip) that uses the Resources construct to this bug. Let us know if you experience any issues.
Posted by Raphael Londner - on 3/6/2013 at 9:01 PM
Hi Iouri,

I just installed the RTM version of the Developer Tools, but it doesn't look it supports the Resources: expression builder, unlike what you wrote below. Can you confirm that this is the case, and is the workaround you mention the only viable solution at this stage? This would look like a huge step backwards...
Posted by Raphael Londner - on 2/21/2013 at 9:20 AM
Hi Iouri,

Thank you for providing the fixed solution, this makes things indeed easier to understand. I look forward to the final release of the Developer Tools with support of the Resources: expression builder though, if that's still in the plans.

Posted by Iouri [MSFT] on 1/22/2013 at 6:25 PM
Hello Raphael,
In the attached project you will find changes with the workarounds I proposed. I hope this makes things more clear. I did not mark the issue as fixed - somebody else must have done it. I apologize for the inconvenience and I am truly sorry that I am not able to give you dates or formal engagement to fix the issue - you should watch for a public announcement.
As you will see in the sample, even though resources are duplicated (both the resx and the DLL are deployed, and they both contain them), in reality they are produced from the same source (the RESX) so maintenance tax is very low.
Posted by Raphael Londner - on 1/22/2013 at 7:05 AM
Hi Anatoly,

Thank you for the pointer to your blog! However, as you mentioned, I now prefer to stick to Microsoft templates. I've used the SmartPart and WSPBuilder in quite a few projects, even after the SharePoint 2010 tools were released, but since all those efforts are no longer supported, you hit a wall at some point and must migrate to the officially supported tools, as inconvenient as they might be. Sometimes, it'd be nice if the MS dev team actually got inspired from and incorporated some community efforts into their dev tools instead of trying to re-invent the wheel or switch gears at every new release.

How bad can it be to actually listen to your developer community? For instance, we still have to rely to VS plugins to achieve things as trivial as "Copy to SP Hive" or "Copy to GAC" actions, which are particularly useful when re-deploying a solution is unnecessary and an overkill? Obviously, with the new Visual Web Part, re-deploying is now a requirement (which clearly s***s big time). Let's say goodbye to developer productivity!
Posted by Raphael Londner - on 1/22/2013 at 6:44 AM
Hi Iouri,

I appreciate the feedback, though I am only midly satisfied with it. Here are the reasons why:

1. I was asked to provide a full project that reproduced the issue, but you only responded with a workaround posted on a Microsoft forum, with configuration steps that are difficult to grasp. The least you could have done would have been to re-submit my project with the workaround, so that everyone can easily figure out how to configure the resource files.
2. You are marking this issue "Resolved as fixed", while clearly there is no current fix. There is only a workaround, which brings us back to ASP.NET 1.1 development practices (code behind for localization).
3. You write that you are planning to add support for the Resources" expression builder, but you don't state when this feature will be available.

That said, to answer your question, I assume that yes, loading from assembly resources instead of global resources could work, but I think you need to approach the problem in a larger context, because in full-trust solutions resource files are used not only to localize web parts, but also feature titles, descriptions, custom ECB menus, etc... So the larger question is: if we have to switch to assembly resources for visual web parts to work, will we also be able to use the resource files to localize other SharePoint artifacts (such as feature definitions, ECB menus, etc...) or will we have to maintain 2 different sets of resources for each project?

BTW, the SharePoint Developer Tools have been in Preview mode for quite a while, but SharePoint 2013 has been released last November. Can you give us a hint of the RTM date for the developer tools?


Posted by Iouri [MSFT] on 1/21/2013 at 4:56 PM
Thank you for bringing the issue to our attention!
The preview bits do not allow using resources in markup. I posted a comment at http://social.msdn.microsoft.com/Forums/en-US/sharepointdevelopment/thread/af139e08-4d64-4685-b1d8-b3e03a9b748d that explains the workaround.
We want the visual web part to be useful in sandboxed solutions as well as in farm solutions. Global resources can only be deployed in the latter case. For that reason, we are planning to add support for the Resources: expression builder that would load from assembly resources rather than from global resources.
Essentially, Text="<%$Resources:test,Label1%>"> will be equivalent to writing Label1.Text=test.Label1; in the code-behind file.
Please let us know if that would be an acceptable resolution for this issue.
Posted by A Chuvash Guy on 1/20/2013 at 6:14 AM
I have written a blog about how to use the old template for a visual webpart. http://sharepointkunskap.wordpress.com/2012/09/20/the-original-visual-web-part-template-is-missing-in-visual-studio-2012/ But it is better to use the new template.
Posted by Maik van der Gaag on 1/16/2013 at 12:24 AM
I'am having the same problem. Is there coming a resolution?
Posted by Microsoft on 1/14/2013 at 2:45 AM
Hi Raphael, thanks for your response, we have received your attached files. Your issue has been routed to the appropriate VS development team for investigation. We will contact you if we require any additional information.
Posted by Raphael Londner - on 1/11/2013 at 12:13 AM

I have just attached a LocalizedVisualWebPartFixed.zip sample visual web part project that contains the following line in the VisualWebPart1.ascx file:

<asp:Label ID="Label1" runat="server" Text="<%$Resources:test,Label1%>"></asp:Label>
Posted by Microsoft on 1/10/2013 at 11:11 PM
Hi Raphael, we want to remind you we need a demo project. Please reply to us as soon as possible. Thanks.
Posted by Microsoft on 1/9/2013 at 9:14 PM
Thank you for submitting feedback on Visual Studio and .NET Framework. In order to efficiently investigate and reproduce this issue, we are requesting a demo project. Please submit this information to us within 4 business days. We look forward to hearing from you with this information.
Posted by Microsoft on 1/9/2013 at 5:52 PM
Thank you for your feedback, we are currently reviewing the issue you have submitted. If this issue is urgent, please contact support directly(http://support.microsoft.com)