Designer fails to load a valid Form (mess up with dependencies assemblies ?); (Unknown Type during OnMethodPopulateStatements.) - by C.h.a.c.h.a_

Status : 

  Won't Fix<br /><br />
		Due to several factors the product team decided to focus its efforts on other items.<br /><br />
		A more detailed explanation for the resolution of this particular item may have been provided in the comments section.


1
0
Sign in
to vote
ID 362608 Comments
Status Closed Workarounds
Type Bug Repros 0
Opened 8/20/2008 2:54:24 AM
Access Restriction Public

Description

Hello,

As usual, the problem is the Designer that suddenly cannot load a Form any more.
I suspect a mess in loading dependent assemblies at design-time.
I had the problem with VS2005, and upgrading to VS2008 did not help.
I cannot send the project, which is big and private code, but I will try to decribe as precisely as possible.

1)Structure
2)What works
3)What does not work
4)What I suspect

[1-Structure]
-I have in fact 6 projects, each one in its own directory. There is a tree of logical dependencies.
Project A depends on none. It is a DLL assembly
Project B depends on none. It is a DLL assembly.
Project Cab depends on A,B. It is a DLL assembly. Contains Windows Forms/User controls to be used in other projects.
Project Dab depends on A,B. It is a DLL assembly
Project Eabcd depends on A, B, C, D. It is a DLL assembly. Contains Windows Forms/User controls to be used in other projects.
Project Fabcde depends on a, b, c, d, e. It is an executable assembly

To handle the dependancies, I have used the regular way : each project is a VisualStudio "Solution", and I have attached "existing items" to this solutions, these items being the other projects.
Moreover, I have also added the assemblies in the references, using "Project > Common Properties > References >Add New references", then selecting the assembly in the "project" tab.

I usually only load the Fabcde Solution in VS, since, I can reach each project from there.

[2-What works]
-Each project compiles very well
-The executable assembly runs without problem
-The projects Cab and Eabcd contains windows forms/user controls. I can open thoses forms/controls in the designer without problem

[3-What does not work]
-Project Fabcde contains Windows Forms/User controls that use custom controls from Cab and Eabcd. Suddenly, I could not open such forms any more, the designer claiming that a type from Eabcd cannot be found. It also claims that types form Fabcde itself cannot be found ?! (Which is the most stupid error)

-If I open a form of Fabcde that does not use custom controls, it loads ok in the designer, and the ToolBox contains my custom controls from Cab and Eabcd. But if I try to instanciate  such a custom control fro mEabcd, it outputs an error
System.IO.FileNotFound exception : cannot load the assembly A. (The constructor from the custom controls actually makes calls to A).
As you can see, the only culprit is the designer that fails at loading assembies. However, he is alone to fail. Everybody else is able to find the assembly.

-Of course, I have tried to regenerate each project, to clear the ProjectAssembly cache, to add a FullTrust rule in the .NET config that points to the ProjectAssembly URL...

[4-What I suspect]
I suspect that the designer, for some reason, has a buggy way to resolve dependencies. Sometimes it works, sometimes it does not.
Sign in to post a comment.
Posted by Microsoft on 9/25/2008 at 1:52 PM
Hi Pierre,

Unfortunately we cannot devote the resources necessary to make the designer less fragile. We are focusing our efforts on improving native development going forward. Our general recommendation is to write an interop layer in C++/CLI and use C# forms for UI.

Thanks,
Visual C++ Team
Posted by C.h.a.c.h.a_ on 8/21/2008 at 6:15 AM
>1)Instead of making the calls to outside assemblies in the contructor, make them in OnLoad instead.
>2) Only call the external assemblies if DesignMode is false
It just worked. I have added some guards to skip part of codes when I am in Design mode. I hope that solution will work when it will be broken again :-)
Thanks !

However, I will keep this thread alive until there are some news about fixing the bug of the Designer not using the very last assemblies in the dependancies.
Posted by C.h.a.c.h.a_ on 8/21/2008 at 1:29 AM
>"And if your build occurs only in the Solution, it is true that the Debug folders of the sub-projects are not updated."
>That is not the case.
Yes it is ! (I've just checked again)
Let me detail the structure
ProjectA
|_trunk (yes I use SVN)
     |_Project1.sln
     |_ProjectA
     | |_ProjectA.vcproj
     | |_source files...
     | |_Debug
     |     |_object files
     |_Debug
        |_ProjectA.dll

Now, imagine the same structure for a ProjectB. But the "Solution" for project B is using a project reference to ProjectA.
Now, in ProjectB, modify some file of ProjectA
Build : VS automatically tracks that ProjectA needs to be recompiled
Recompilation of ProjectA and ProjectB occur

The result is :
in the Debug folder of ProjectB, ProjectA.dll and ProjectB.dll are generated. But in the Debug folder of ProjectA, ProjectA.dll remains untouched.

>It is a well known problem that once the designer has loaded an assembly, even if that assembly is a project reference, if you rebuild that assembly, the designer will not pick up those changes. I can't tell from your bug description: is that the kind of thing you are talking about?
It could be such a bug. How do I do to "refresh" the Designer so that it is using the new assemblies ?

Regards,
Posted by Microsoft on 8/20/2008 at 9:46 PM
Thanks for your feedback. We are escalating this bug to the product unit who works on that specific feature area. The team will review this issue and make a decision on whether they will fix it or not for the next release.

Thank you,
Visual Studio Product Team
Posted by David A Nelson on 8/20/2008 at 4:25 PM
"And if your build occurs only in the Solution, it is true that the Debug folders of the sub-projects are not updated."

That is not the case. When you build a solution, the projects in the current build configuration are built in the order of their dependencies. Each project's output is copied to its own ouput directory (usually bin\<config>). Subsequent project which have project references take the output of those projects and copy them to their own obj directory, execute the build, and then copy the dependent assemblies from obj to the project's output directory.

It is a well known problem that once the designer has loaded an assembly, even if that assembly is a project reference, if you rebuild that assembly, the designer will not pick up those changes. I can't tell from your bug description: is that the kind of thing you are talking about?
Posted by C.h.a.c.h.a_ on 8/20/2008 at 12:42 PM
This is an idea. I will try and report that tomorrow. However, there is still a problem of Visual Studio itself, that is not able to ensure consistency of the DLL assembly builds. It is advertised that using Project references (as I do) is the best way, because it automatically handles dependencies, build versions, rebuild when needed... the reality with the Designer is that it does not.
Perhaps is this because the Designer does not load the good DLLs (the ones in the Debug folder of the current solution) but the ones in the Debug folder of the sub-projects. And if your build occurs only in the Solution, it is true that the Debug folders of the sub-projects are not updated. Only the Debug folder of the Solution is modified with the new DLLs.
I have tried to add a script to "copy back" the DLLs built by the current solution to the folders of the sub-project, replacing them as necessary. That, plus clearing the ProjectAssemblies cache, did help during a few minutes (the Designer did load again!). But a few builds later, same problem. And replacing the DLLs again did not work, certainly for some reason.

Posted by David A Nelson on 8/20/2008 at 11:37 AM
Try this:

1) Instead of making the calls to outside assemblies in the contructor, make them in OnLoad instead.
2) Only call the external assemblies if DesignMode is false
Posted by C.h.a.c.h.a_ on 8/20/2008 at 3:24 AM
More clues :
In the "Project > Common Properties > References" of my Fabcde solution, I inspect the build numbers of the referenced assemblies. They are ok.
However,if I try to add items in the Designer ToolBox by selecting the Cab DLL in the Fabcde/Debug folder, it fails loading the assembly A. And the build number of the "A" assembly that is not found is not the good one. It is an old one.
S, it seems that there is a mess in the dependencies. Even if I rebuild all, the assemblies do not refer to the last builds of each other.
Posted by C.h.a.c.h.a_ on 8/20/2008 at 2:55 AM
This is a lng run problem (since VS2003 I think...) Isn't there any way to develop a tool that could "check and fix" header files so that the designer is not so fragile any more at loading ?