SharePoint 2013 - Using resource file in webpart, getting blank .ascx.g.cs file: "The name 'InitializeControl' does not exist in the current context."
I am developing a webpart in a new SharePoint 2013 solution. I want to use resource files from a global resource file to fill out controls, like this:
<asp:Literal ID="Literal1" runat="server" Text="<%$Resources:MyResource,LiteralText%>" />
The problem arises when i try to build the solution; the corresponding .ascx.g.cs file is not generated, which results in getting the error message: "The name 'InitializeControl' does not exist in the current context." (This method is normally in the .ascx.g.cs file, though in this case, it is blank)
However if i replace the reference to the resource file with plain text, it builds perfectly without errors, and the .ascx.g.cs file is populated just fine:
<asp:Literal ID="Literal1" runat="server" Text="someText" />
What is causing this? And is there a solution/workaround? I have spent a wast amount of time on this without any luck..
- Edited by Esben Wiberg Thursday, December 13, 2012 5:15 PM
did you check this post: The name InitializeControl does not exist in the current context – Visual Web Part (Sandboxed) bug and how to fix it? By symptoms looks similar to your problem.
Please check if the suggested answer from Waldek in the thread below fits into your issue:
currently there is no way to use global resources in the visual web part because it is compiled to code and the resource has to be available at code generation time.
The workaround is to set the value in code. The resource file does not need to be deployed as a global resource; on the other hand, it has to be translated to code and compiled. Luckily, this is the default behavior for any resx file. You can check if that's the case if the properties of the file show "Custom Tool" as ResXFileCodeGenerator. You should also have MyResource.vb (or MyResource.cs) in your project.
In aspx file, you need to write
<asp:Literal ID="Literal1" runat="server" />
in code behind, you can write
Literal1.Text = MyResource.LiteralText
When you build your assembly, the resource strings will live inside the assembly. You should be able to run the project and est your web part in the default language. After you localize the resources, VS will also build localized assemblies. You would need to use VS package designer to add these assemblies to the WSP.
Here's the sample I used:
<%@ Assembly Name="$SharePoint.Project.AssemblyFullName$" %>
<%@ Assembly Name="Microsoft.Web.CommandUI, Version=184.108.40.206, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
<%@ Register Tagprefix="SharePoint" Namespace="Microsoft.SharePoint.WebControls" Assembly="Microsoft.SharePoint, Version=220.127.116.11, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
<%@ Register Tagprefix="Utilities" Namespace="Microsoft.SharePoint.Utilities" Assembly="Microsoft.SharePoint, Version=18.104.22.168, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
<%@ Register Tagprefix="asp" Namespace="System.Web.UI" Assembly="System.Web.Extensions, Version=22.214.171.124, Culture=neutral, PublicKeyToken=31bf3856ad364e35" %>
<%@ Import Namespace="Microsoft.SharePoint" %>
<%@ Import Namespace="SharePointProject12" %>
<%@ Register Tagprefix="WebPartPages" Namespace="Microsoft.SharePoint.WebPartPages" Assembly="Microsoft.SharePoint, Version=126.96.36.199, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
<%@ Control Language="C#" AutoEventWireup="true" CodeBehind="VisualWebPart1.ascx.cs" Inherits="SharePointProject12.VisualWebPart1.VisualWebPart1" %>
<asp:Literal ID="Literal2" runat="server">
<% Literal2.Text = Resource1.LiteralText; %>
Hope this helps,
I have exactly the same problem here, with VS2012 U1 and the latest version of MS Office Dev extension proposed on web platform installer.
I Tried your workarounds none of these worked. And another fact louri, what you proposed to do is code inline, and it is not recommended by Microsoft for security and performance reasons.
Any Update on this issue?
That's funny seem to be the 2007 when we had the same problem with the Visual Web Part.
BTW I just created a Visual Web Part and I have the same problem. It's a brand new VWP without any customization.
Se il post ti è tornato utile "suggerisci come risposta"
Salvatore Di Fazio
MVP SharePoint Server
I am surprised that the workaround does not work for you. Please check out the full project attached to the following Connect bug : http://connect.microsoft.com/VisualStudio/feedback/details/776185/localization-of-a-sharepoint-visual-web-part-the-name-initializecontrol-does-not-exist-in-the-current-context#details
As to code inline, you are right; inline code is not recommended. However, Visual Web Part in Visual Studio in 2012 does not use it. The term "inline code" refers to managed code that appears inside ASP.Net markup. In case of the visual web parts, the code is inside *.g.cs file - no markup is actually deployed. The code is built inside the application assembly and is as secure and performant as the rest of the code. The ascx file in the project is merely a design-time artifact that allows the use of the visual designer.
Hope this clears the issue.
Found the solution!
Update to vs Update 2, Tools RTM and read this :)
- Proposed as answer by Vincent BIRETMVP Sunday, April 07, 2013 9:24 PM
The intended way for localization in a Visual Web Part is to use managed resources. That way is compatible with Sandboxed as well as Farm solutions.
I uploaded a sample solution (LocalizedVisualWebPartToolsRTW.zip) as an attachment to the Connect bug http://connect.microsoft.com/VisualStudio/feedback/details/776185/localization-of-a-sharepoint-visual-web-part-the-name-initializecontrol-does-not-exist-in-the-current-context#details. It will take a few hours to show up.
Essentially, you can add a file test.resx to your project and use the following markup:
<asp:Label ID="Label1" runat="server" Text="<%$Resources:test,Label1%>"></asp:Label>
Which will load the resource from the main assembly or from a satellite assembly.
An article for SharePoint 2010 explains the details about deploying the satellite assemblies.
Hope this helps,
Thank you for this other workaround! 2 facts to mention:
- Sandboxed solutions are deprecated, Microsoft recommends to switch to apps ASAP if possible
- This workaround introduces another issue, cross referencing between release and debug assemblies. If you reference the release satellite assembly and compile in debug you may have issues packaging (if you made a cleanup in release or got the code from TFS for example). That also may cause issues with Visual Studio checking if the resource exists. A good thing with this workaround would be to instruct reader to edit project output to the same location for debug and release so even if changing the profile, the reference would still be good with no missing satellite assembly and no cross referencing.