可以将文章内容翻译成中文,广告屏蔽插件可能会导致该功能失效(如失效，请关闭广告屏蔽插件后再试):

问题:

I have an ASP.NET web application project which references another project called ModusCore (or Modus.Core). We've had a variety of controls that use ModusCore up until now with no problem, but there's one I created lately that's been causing trouble. Here's the code:

public class PortalLinkNew : WebControl
{
    public string Text { get; set; }
    public bool AllowPush { get; set; }

    public PortalLinkNew()
    {
        AllowPush = true;
    }

    public IChannelRequest ChannelRequest { get; set; }

    protected override HtmlTextWriterTag TagKey
    {
        get { return HtmlTextWriterTag.A; }
    }

    protected override void AddAttributesToRender(HtmlTextWriter writer)
    {
        try
        {
            base.AddAttributesToRender(writer);
            if (DesignMode || Page == null || !(Page is IPortalPage))
            {
                return;
            }
            string href = "/";
            if (ChannelRequest != null)
            {
                var portalPage = (IPortalPage)Page;
                href = portalPage.Module.PortalRouter.GetLinkUrl(portalPage, ChannelRequest, AllowPush);
            }
            writer.AddAttribute(HtmlTextWriterAttribute.Href, href);
        }
        catch (Exception)
        {

        }
    }

    public override void RenderEndTag(HtmlTextWriter writer)
    {
        writer.Write(Text);
        base.RenderEndTag(writer);
    }
}

In the above code, IPortalPage and IChannelRequest are interfaces defined in Modus.Core.

My intent is to use this control in my code as follows:

<tnl:PortalLinkNew ID="CancelButton" runat="server" Text="Cancel" OnInit="CancelButton_Init" />

This actually compiles and runs without a problem, but when I'm editing the page (source view) in Visual Studio 2008, I get the following warning:

Generation of designer file failed: Could not load file or assembly 'Modus.Core, Version=1.0.0.0, Culture=neutral, PublicKeyToken=null' or one of its dependencies. The system cannot find the file specified.

As it says, it doesn't regenerate the designer file, meaning any attempt to refer to the CancelButton control in code-behind results in a compiler error. Following advice I've found online, I've tried deleting the corresponding .ascx.designer.cs file and using "Convert to Web Application" on that page, but it tells me that it cannot rebuild the designer file for the same reason mentioned above.

I've tried everything I can think of: cleaning the solution, restarting Visual Studio, rebooting my computer, deleting the code directory and pulling it fresh from the repository, removing and re-adding the project and dll references, etc. The same problem occurs on multiple computers I use.

How can I get the VS designer to stop failing?

回答1:

I have a very similar problem (which I could not solve yet). The Application I have the problem with was converted from a "Web Site Project" though and I can't get rid of the feeling that this has something to do with it. And I am on VS 2005.

Now what I can add is that

a) "sometimes" (I could not figure out when exactly yet) the "Convert to Web Application"-trick works for me (but not always)

b) "sometimes" (same as above) it helps to switch to the designer view, change something and save -> *.designer.cs gets regenerated

I usually try several things in no fix order after I added a control to my page until "something" works.

There is a lot of noise about this on the internet but I could not find a "real fix" for it (yet). One thing I read besides the already mentioned is that it could have something to do with (not matching/not existing) namespaces.

When I checked my application there really were no namespace declarartions in the *.cs-files. So I added them (in *.cs and *.aspx) and for some time thought it did the trick. But sadly by now I know that this was not the case...

回答2:

My solution:

Close and reopen Visual Studio.
Is your problem fixed? If not, go to 1.

回答3:

Adding a third option for when @scherand's (a) and (b) fail:

c) "Sometimes", this works as well:

Remove the <%@ Register... %> entries
Save the .AS?X file. Let the designer complain.
Add the <%@ Register... %> again
Save again

[Added Oct-13-2010]:
d) "Sometimes", as well:

Clear the AS?X file off all but the most basic content.
Start adding pieces back, one bit a time.
Save.
Check that you didn't get the error message.
Add back a few more pieces. Rinse. Repeat.

I use a text comparison tool against a back up copy of the AS?X file for this.

I try to avoid adding the controls that cause the error until the very end. I also try to add from the bottom of the page. However, I don't know of a hard rule. It's a gut-feeling exercise.

(Will someone ever figure this one out?)

回答4:

I've been struggling with this problem all day, and you wouldn't believe what the culprit was. I disabled ReSharper 5.0 and all of a sudden the errors went away. Unbelievable.

回答5:

Another solution I have found to be effective in Visual Studio 2015 is to close VS and then clear out the following directories:

%UserProfile%\AppData\Local\Temp\Temporary ASP.NET Files\
%UserProfile%\AppData\Local\Microsoft\VisualStudio\14.0\ProjectAssemblies\

Open your solution again and select Build->Clean Solution.

Now go to your ASPX page, and then select Project->Convert To Web Application

回答6:

Copying the missing assemblies into the Visual Studio\Common7\IDE\Public Assemblies directory gave me more specific error messages than 'could not load file or assembly'. From here I commented out some problematic parts of the page, deleted the .designer.cs file and chose "Convert to Web Application" from the right-click context menu of the .ascx file.

回答7:

Well, I've had this very problem for two days. As far as no proposed solution completely solved the problem (it looks very... erratic), I reached the Assembly Information button (or something similar... my VS is in Spanish) in the Application Tab of the project properties. I've only changed the Neutral Language... and now it deploys correctly.

I have no idea of the correlation, but I reached here after seeing how some errors, related to the assembly information were displayed on the console after "converting to Web Application".

To ensure that your web application is OK to deploy, you can see the first lines of the aspx files and check if all CodeFiles are CodeBehind instead. If you see "Codefile=...", it will fail on the deployment machine.

Sorry for not being more explicit, but this is a weird issue to me :S

回答8:

I had a similar issue but with assemblies that we had created. In our case the version number was very specific, so this may not work if all your files say 1.0.0.0.

First of all, delete the designer file for the problematic aspx file. Right-click the aspx file and select "Convert to Web Application", similar to what others suggested. Doing it on the file is faster and you get a popup with the error instead of a warning you have to look for. In our case the error was Generation of the designer file for OurPage.aspx failed: Could not load file or assembly 'OurCustomAssembly, Version=1.0.234.567...

What I then did is use a tool that searches file contents (e.g. Agent Ransack) and pointed it to our source folder (which also has the build/cache files) and searched for files "containing text" with the specific version. For each of the projects that came up, I removed the reference to the assembly that was failing, re-added it, then rebuilt the individual project. Searching again showed that the version was gone.

I ran Convert to Web Application again and now got the same error but with a different file. This time none of the above worked. I was able to determine that only some of the Register tags were problematic. I removed those register tags, created protected variables on the page's code-behind (since they weren't in the designer file) and recompiled the solution. Afterwards I removed the variables I had created, saved, readded all the Register tags, saved. At that point the designer file generated successfully.

There may be a more straightforward way to do all this, but that's what ended up working for me. Time will tell, but hopefully this is a permanent fix.