SharePoint 2013 - Using resource file in webpart, getting blank .ascx.g.cs file: "The name 'InitializeControl' does not exist in the current context."
Thursday, December 13, 2012 5:14 PMHey,
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
Thursday, December 13, 2012 9:22 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.
Friday, December 14, 2012 8:23 AM
that is a post without any real solution for me. The problem is NOT the same and the solution is updating VS2010; I'm using VS2012.
But thanks anyway..
- Edited by Esben Wiberg Friday, December 14, 2012 8:42 AM
Wednesday, December 19, 2012 4:01 AM
Did you manage to solve the problem !? i am stuck here :/
i updated my VS to SP1 also with no luck...
Thanks Mohd Al-Bakri
Wednesday, December 19, 2012 6:32 AM
try like this and let us know if this works
In code behind
string x = convert to string "<%$Resources:MyResource,LiteralText%>"
SP Page: http://www.facebook.com/SharePointQ SP Blog: http://swatipoint.blogspot.com/
- Edited by MsSPJ Saturday, January 19, 2013 4:40 PM
Thursday, December 27, 2012 5:10 PMAnswerer
Please check if the suggested answer from Waldek in the thread below fits into your issue:
Monday, January 07, 2013 11:32 AMNopes this is not a solution for my problem.. But thanks anyway..
Friday, January 18, 2013 7:15 PM
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=220.127.116.11, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
<%@ Register Tagprefix="SharePoint" Namespace="Microsoft.SharePoint.WebControls" Assembly="Microsoft.SharePoint, Version=18.104.22.168, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
<%@ Register Tagprefix="Utilities" Namespace="Microsoft.SharePoint.Utilities" Assembly="Microsoft.SharePoint, Version=22.214.171.124, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
<%@ Register Tagprefix="asp" Namespace="System.Web.UI" Assembly="System.Web.Extensions, Version=126.96.36.199, Culture=neutral, PublicKeyToken=31bf3856ad364e35" %>
<%@ Import Namespace="Microsoft.SharePoint" %>
<%@ Import Namespace="SharePointProject12" %>
<%@ Register Tagprefix="WebPartPages" Namespace="Microsoft.SharePoint.WebPartPages" Assembly="Microsoft.SharePoint, Version=188.8.131.52, 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,
Friday, February 01, 2013 6:59 AM
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?
Thursday, February 14, 2013 2:16 PM
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
Sunday, February 17, 2013 1:30 AM
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.
Monday, February 18, 2013 3:29 PM
Your workaround works but it is actually code inline <% Literal2.Text = Resource1.LiteralText; %> that is not recommanded for performance and security issues.
Sunday, April 07, 2013 9:24 PM
Found the solution!
Update to vs Update 2, Tools RTM and read this :)
- Proposed As Answer by Vincent BIRET Sunday, April 07, 2013 9:24 PM
Wednesday, May 01, 2013 12:46 AM
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,
Thursday, May 02, 2013 3:11 AMIouri,
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.