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

Raphael,
I uploaded a solution (LocalizedVisualWebPartToolsRTW.zip) that uses the Resources construct to this bug. Let us know if you experience any issues.
Iouri

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...

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.

Thanks,
Raphael.

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.
Thanks,
iouri

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!

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?

Thanks,

Raphael.

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.
Thanks,
iouri

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.

I'am having the same problem. Is there coming a resolution?

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.

Hello,

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>

Hi Raphael, we want to remind you we need a demo project. Please reply to us as soon as possible. Thanks.

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.

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)