none
SharePoint 2013 - Using resource file in webpart, getting blank .ascx.g.cs file: "The name 'InitializeControl' does not exist in the current context."

    Question

  • Hey,


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


    Best regards
    Esben Wiberg



    • Edited by Esben Wiberg Thursday, December 13, 2012 5:15 PM
    Thursday, December 13, 2012 5:14 PM

All replies

  • Hey,

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

    \Esben

    Friday, December 14, 2012 8:23 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 4:01 AM
  • Hi

    Please check if the suggested answer from Waldek in the thread below fits into your issue: 

    http://social.msdn.microsoft.com/Forums/en-US/sharepointdevelopment/thread/a343360a-6e46-435b-ba26-bbda3fc3c4f8


    Kind Regards

    Bjoern
    http://spviking.com
    Twitter: Follow @bjoern_rapp

    Thursday, December 27, 2012 5:10 PM
    Answerer
  • Nopes this is not a solution for my problem.. But thanks anyway..
    Monday, January 07, 2013 11:32 AM
  • Hi Esben,

    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=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
    <%@ Register Tagprefix="SharePoint" Namespace="Microsoft.SharePoint.WebControls" Assembly="Microsoft.SharePoint, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
    <%@ Register Tagprefix="Utilities" Namespace="Microsoft.SharePoint.Utilities" Assembly="Microsoft.SharePoint, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
    <%@ Register Tagprefix="asp" Namespace="System.Web.UI" Assembly="System.Web.Extensions, Version=4.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" %>
    <%@ Import Namespace="Microsoft.SharePoint" %>
    <%@ Import Namespace="SharePointProject12" %>
    <%@ Register Tagprefix="WebPartPages" Namespace="Microsoft.SharePoint.WebPartPages" Assembly="Microsoft.SharePoint, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
    <%@ Control Language="C#" AutoEventWireup="true" CodeBehind="VisualWebPart1.ascx.cs" Inherits="SharePointProject12.VisualWebPart1.VisualWebPart1" %>
    <asp:Literal ID="Literal2" runat="server">
    </asp:Literal>
    <% Literal2.Text = Resource1.LiteralText; %>

    Hope this helps,

    iouri

    Friday, January 18, 2013 7:15 PM
  • Hi Everybody,

    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?


    Cya

    Friday, February 01, 2013 6:59 AM
  • 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
    salvatoredifaziosharepoint.blogspot.com

    Twitter: @Salvodif
    MVP SharePoint Server

    Thursday, February 14, 2013 2:16 PM
  • Vincent,

    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

     to see if it works for you.

    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.

    Sunday, February 17, 2013 1:30 AM
  • Louri,

    Your workaround works but it is actually code inline <% Literal2.Text = Resource1.LiteralText; %> that is not recommanded for performance and security issues.

    Regards


    Cya

    Monday, February 18, 2013 3:29 PM
  • Sunday, April 07, 2013 9:24 PM
  • Vincent,

    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,

    iouri

    Wednesday, May 01, 2013 12:46 AM
  • Iouri,
    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.
    Vincent

    Cya

    Thursday, May 02, 2013 3:11 AM