Hi all,
I was wondering if someone else was experiencing the same problem. I have created some controls inheriting from Infragistics controls. But when I use these objects on a form and open this form in the Designer, it is terribly slow. The time needed to load the form in the designer depends on the number of custom controls used on the form, but the avrage extra load time I experience is about 1 to 2 seconds per object!
Does anyone have the same problem? What could be the cause of this? what can be done to solve this?
Kees Vlasblom
Hello Kees,
An issue like this was reported for 10.2A and fixed in 10.2A01.
The load time depended on the number of assemblies used by the application.
Do you have assemblies in the assemblies.xml file that are not really needed?
If so, you could remove them from the assemblies.xml file to reduce the load time.
For better results, look for 10.2A01 when it comes out.
Regards,
Edsel
Thanx, i will wait for 10.2A1
How can you tell which assemblies you need and which you don't?
Trial and error
One way of dealing with the assemblies.xml file is to let the Visual Designer add the required assemblies whenever you add a new Control to a form for the first time. Of course it will never remove an assembly that you have just tried.
Another drawback is that the class browser only shows type information for classes that are contained in the assemblies.xml' Assebmlies. So I'd rather wait for SP1.
There is no button push that will tell you, although that would be nice and is possible to do with the right tools. This would be a good addition to a deployment tool.
You can generally eliminate anything that has Design in the name. You can probably also eliminate anything with VisualBasic in the name as well. Deployment and Serialization can probably be eliminated in most cases.
The rest of the stuff you probably need.
A lot of these "extra" assemblies are included as dependencies of an assembly and are automatically included by the VD when you add a control to a form because somewhere in the assembly is a reference to the "extra" assembly, even if you probably don't need it. The down side is that the VD will put them back the next time you use a new control that references them.
If one of these "extra" assemblies is referenced by one of the assemblies actively used in your project, and the required assembly is present in the GAC, then the CLR will pull in the assembly from the GAC without you having to reference it explicitly in the assemblies.xml.
Until you are ready to deploy, you are better off just leaving them, since the VD will put them back anyway the next time you add a control that references them.
Disclaimer: unless you are know what you are doing, don't remove an assembly reference from the assemblies.xml for your project. Since it might be needed and you don't realize it.
The class browser is fully capable of showing .pl, r-code directories, and assemblies from the GAC and from a .dll even if not explicitly referenced from a project. In the menubar for the class browser is a button that lets you add 'external' resources. This opens a dialog where you can add any of the above and they will be shown in the class browser with everything else.
That's cool stuff and I was very surprised to see the class browser "remembering" the external assemblies.
Where are they stored? In the project or in the workspace?
There is a config file in the workspace that stores the list of "external" references.
This does appear to be resolved in 10.2A SP1.