I'mimplemented a forms editing environment based on the MSDN example: http://msdn.microsoft.com/msdnmag/issues/06/03/designerhosting/default.aspx.My DesignerLoader derives from CodeDomDesignerLoader, and I'd like to persist the form definition to a file so that it can be subsequenly reopened and edited. I can persist the CodeCompileUnit to a file using the BinaryFormatter, and I can recreate the CodeCompileUnit from the file using the following code:

I return the inflated CodeCompileUnit from my implementation of CodeDomDesignerLoader.Parse, but the form is only properly reconstructed in the form designer if it contains no child controls.As soon as I add a child control (doesn't matter which one), I'm unable to restore the form using the persisted CodeCompileUnit. Note that I have this problem even if the child controls do not reference resource data. What do I need to do to successfully restore the form from persistent storage?

Thanks,

Bill

I think I've identifed the problem.

I have used the same example and BinaryFormater to persist. There is nothing wrong with the formater. The problem is with the referenced assembly.At the end ofLoder.CodeGen.GetCodeCompileUnit(IDesignerHost host) function, I added controls and set thier properties, except the properties that need System.Drawing and works fine. But It doesn't work when I try to set Size or Location. I checked the codeCompileUnit.ReferencedAssembly when the Loader.CodeDomHostLoader.Parse() returns the ccu and it contains System.Drawing but I don't know why it only works for references to System.Wndows.Forms.

If you find theanswer please post it.

I'm afraid I never found an answer to this issue. I opened a support incident with MS about it, and the support engineer I spoke with got in touch with the author of the MSDN article who said it was not possible to persist and restore forms using the CodeDomDesignerLoader. At that point, I switched to using XML for persistence.

I've got it! It works!

I read an article on http://blogs.msdn.com/ploeh/archive/2006/02/16/TowardsUnitTestingComponentSerializers.aspxand it's simple.

The problem is the GetType(string name, bool throwOnError, bool ignoreCase) method of TypeResolutionService class. The CodeDomeDesignLoader uses this method to resolve any Type, and in the sample code the method looks for a Typeonly in System.Windows.Forms.

Replace it with this one and it will work.

public Type GetType(string name, bool throwOnError, bool ignoreCase)

if (ht.ContainsKey(name))

return (Type)ht[name];

AssemblyName[] names = Assembly.GetExecutingAssembly().GetReferencedAssemblies();

for (int i = 0; i < names.Length; i++)

{

Assembly assembly = Assembly.Load(names);

Type[] types = assembly.GetTypes();

string typeName = String.Empty;

foreach (Type type in types)

{

if (type.FullName == name)

{

ht[name] = type;

return type;

}

}

}

return Type.GetType(name);

Does this handle the resx file as well? What if you add components to the surface that require storage in the resource file, does the CodeDom instance maintain that at as well? And when you finally try to create code does it produce 1 file or 2?

I have a surface designer working but I can't see how to get what would be the resx file.