Designer error
-
Got a "crash" in the designer. I have a custom form that has almost no code in it and works fine, both in code and in the designer. I create a new inherited form from that custom form. The inherited form *immediately* (i.e. I make no changes from the code that is generated) shows the following error when I try to open it in the designer: "Object reference not set to an instance of an object". Note that the inherited form and the base form are NOT in the same assembly, but the inherited form's assembly DOES reference the base form's assembly. Also note that the code compiled just fine, and runs fine when I create an instance of the inherited form. Any takers? ~Steve
-
Got a "crash" in the designer. I have a custom form that has almost no code in it and works fine, both in code and in the designer. I create a new inherited form from that custom form. The inherited form *immediately* (i.e. I make no changes from the code that is generated) shows the following error when I try to open it in the designer: "Object reference not set to an instance of an object". Note that the inherited form and the base form are NOT in the same assembly, but the inherited form's assembly DOES reference the base form's assembly. Also note that the code compiled just fine, and runs fine when I create an instance of the inherited form. Any takers? ~Steve
Where the classes are (i.e., in what assembly) doesn't matter so long as the assemblies are resolvable by the project that use types in those assemblies. This could be your problem. Design-time components should typically be installed into the GAC for this very reason. See How the Runtime Locates Assemblies[^] in the .NET Framework SDK for more information. You should also consider debugging VS.NET. Yes, that's right. Open another instance of VS.NET and either attach to the former devenv.exe process or start a new one. Open your projects (works best with debug builds, of course) and try designing your components. It's fairly common to do so when extending the design-time capabilities of your components.
Microsoft MVP, Visual C# My Articles
-
Where the classes are (i.e., in what assembly) doesn't matter so long as the assemblies are resolvable by the project that use types in those assemblies. This could be your problem. Design-time components should typically be installed into the GAC for this very reason. See How the Runtime Locates Assemblies[^] in the .NET Framework SDK for more information. You should also consider debugging VS.NET. Yes, that's right. Open another instance of VS.NET and either attach to the former devenv.exe process or start a new one. Open your projects (works best with debug builds, of course) and try designing your components. It's fairly common to do so when extending the design-time capabilities of your components.
Microsoft MVP, Visual C# My Articles
Heath, thanks for the reply. I'll give it a go. Is there anything I should know about installing things into the GAC? If my base form and inherited form are both changing frequently, should I just put a post-build event to install dll's into the GAC after each build? I'm guessing that after a while I'll end up with a ton of useless versions of my dll in the GAC that way. Should I make "uninstall previous" and "install current" post-build events? Again, thanks for your help... ~Steve
-
Heath, thanks for the reply. I'll give it a go. Is there anything I should know about installing things into the GAC? If my base form and inherited form are both changing frequently, should I just put a post-build event to install dll's into the GAC after each build? I'm guessing that after a while I'll end up with a ton of useless versions of my dll in the GAC that way. Should I make "uninstall previous" and "install current" post-build events? Again, thanks for your help... ~Steve
For one, don't use automatic versioning (i.e., using an asterisk (*) in your
AssemblyVersionAttribute). Fix your version numbers using a versioning schema to your liking. Version numbers on .NET assemblies actually mean something unlike version numbers for Win32 executables. If a two Types differ only by version numbers, they are not the same Type. If you're going to install into the GAC, you have to sign your assembly (which you should do anyway - there's never an excuse not to). Use sn.exe -k KeyFile.snk to generate a key pair named KeyFile.snk (or whatever you want to call it) and set the path in yourAssemblyKeyFileAttribute, or install it into a CSP using sn.exe -k KeyPair.snk MyKeyPair and use that name ("MyKeyPair") in yourAssemblyKeyNameAttribute. I recommend using the same key pair for all your assemblies, or at least all your assemblies for a particular product. You don't need to uninstall these as the GAC allows for side-by-side versioning of assemblies. If these assemblies are changing often, however, I recommend that that you don't install into the GAC and make sure you set up a Project reference - not a simple assembly reference - in your multi-project solution so that Project B has a dependency on Project A - not Project A's assembly. This keeps versions and builds of assemblies in sync and you should not have the problems you're having (unless something else is causing it, of course).Microsoft MVP, Visual C# My Articles
-
For one, don't use automatic versioning (i.e., using an asterisk (*) in your
AssemblyVersionAttribute). Fix your version numbers using a versioning schema to your liking. Version numbers on .NET assemblies actually mean something unlike version numbers for Win32 executables. If a two Types differ only by version numbers, they are not the same Type. If you're going to install into the GAC, you have to sign your assembly (which you should do anyway - there's never an excuse not to). Use sn.exe -k KeyFile.snk to generate a key pair named KeyFile.snk (or whatever you want to call it) and set the path in yourAssemblyKeyFileAttribute, or install it into a CSP using sn.exe -k KeyPair.snk MyKeyPair and use that name ("MyKeyPair") in yourAssemblyKeyNameAttribute. I recommend using the same key pair for all your assemblies, or at least all your assemblies for a particular product. You don't need to uninstall these as the GAC allows for side-by-side versioning of assemblies. If these assemblies are changing often, however, I recommend that that you don't install into the GAC and make sure you set up a Project reference - not a simple assembly reference - in your multi-project solution so that Project B has a dependency on Project A - not Project A's assembly. This keeps versions and builds of assemblies in sync and you should not have the problems you're having (unless something else is causing it, of course).Microsoft MVP, Visual C# My Articles
Excellent! Thanks a bunch for all the info. I will definitely plan on doing all of this (probably won't use the GAC, but WILL strongly name my assemblies). I have indeed solved the problem with the designer (problem in original post), but see that I have some work to do in configuring my projects/assemblies. One last question... you mention setting my version with the
AssemblyVersionAttribute. That is fine, but this project will have 20+ assemblies once it is complete. I don't want to have to go into each assembly and update the build number for every "internal" build (about once every 3 days) and for each release of the project. Is there a good way to make that happen dynamically? (ok, now that I think about it, I should probably search the site for an article...) Anyway, thanks again! You've been a real help. ~Steve -
Excellent! Thanks a bunch for all the info. I will definitely plan on doing all of this (probably won't use the GAC, but WILL strongly name my assemblies). I have indeed solved the problem with the designer (problem in original post), but see that I have some work to do in configuring my projects/assemblies. One last question... you mention setting my version with the
AssemblyVersionAttribute. That is fine, but this project will have 20+ assemblies once it is complete. I don't want to have to go into each assembly and update the build number for every "internal" build (about once every 3 days) and for each release of the project. Is there a good way to make that happen dynamically? (ok, now that I think about it, I should probably search the site for an article...) Anyway, thanks again! You've been a real help. ~SteveYou won't really find any articles on this. I manage a project with over 60 assemblies (it's a massive N-tier application with several alternative tiers and utilities). Automatic versioning was a nightmare. I quickly threw that out and went with a simple approach. The major and minor version numbers don't change very often at all. The build number (the third number) is the number of days since Jan. 1, 2000 (wrote a simple program to calculate that) for the milestone. The revision is incremented for any changes done between milestones that must be published into the test directories. See, the assembly version is really most important when you deploy your assemblies. Since one alternative tier of our application uses touchless dpeloyment over the Internet, Fusion (part of the assembling binding in the .NET Framework) downloads and caches assemblies based on their version number into the Temporary Assembly Cache (also allows for side-by-side versioning). If you fixed a bug and re-released an assembly with the same version, it may not be downloaded to clients who got the first one. That's when changing the versions is most important. You really don't need to change it in between builds when just testing on your machine. This also causes massive nightmares when you use late-binding, i.e. instantiating Types using .NET reflection (like
Activator.CreateInstance; building plug-in style applications or using the provider pattern). You can use publisher policies (specially named assemblies, roughly) and/or theassemblyBindingsection of the .config file to redirect assembly versions. you should read Redirecting Assembly Versions[^] in the .NET Framework SDK for more information if you're interested.Microsoft MVP, Visual C# My Articles
-
You won't really find any articles on this. I manage a project with over 60 assemblies (it's a massive N-tier application with several alternative tiers and utilities). Automatic versioning was a nightmare. I quickly threw that out and went with a simple approach. The major and minor version numbers don't change very often at all. The build number (the third number) is the number of days since Jan. 1, 2000 (wrote a simple program to calculate that) for the milestone. The revision is incremented for any changes done between milestones that must be published into the test directories. See, the assembly version is really most important when you deploy your assemblies. Since one alternative tier of our application uses touchless dpeloyment over the Internet, Fusion (part of the assembling binding in the .NET Framework) downloads and caches assemblies based on their version number into the Temporary Assembly Cache (also allows for side-by-side versioning). If you fixed a bug and re-released an assembly with the same version, it may not be downloaded to clients who got the first one. That's when changing the versions is most important. You really don't need to change it in between builds when just testing on your machine. This also causes massive nightmares when you use late-binding, i.e. instantiating Types using .NET reflection (like
Activator.CreateInstance; building plug-in style applications or using the provider pattern). You can use publisher policies (specially named assemblies, roughly) and/or theassemblyBindingsection of the .config file to redirect assembly versions. you should read Redirecting Assembly Versions[^] in the .NET Framework SDK for more information if you're interested.Microsoft MVP, Visual C# My Articles
Hmmm, well you've definitely caught my attention. I've been developing C++ for some time now, but this is my first go at .NET. I'm quickly learning that I have a ton to learn. Thanks for the lesson (and the link). I'll start doing my homework now ;-) ~Steve