registry size and the GAC

[Bob]

My question about how to add an assembly search path to VS.NET's IDE remains
unanswered, but I'm still faced with a problem possibly associated with
this: my exported registry is more than 67MB. This seems much too large to
be normal, even for a developer's machine.

I've read in places that "it's not recommended that you register assemblies
in the GAC when developing addins", yet the instructions for adding a path
the IDE configuration are for an XML file that looks nothing like the 2003
version, so whenever I revision my controls DLL, I have to re-register it
(and a couple of other DLL's) into the GAC and delete the old ones
(manually, from C:\Windows\Assembly) if I want my addin to work with the
updated control set. Since these DLL's are registered to COM, I strongly
suspect that the numerous adds and deletes of these DLL's to and from the
GAC have contributed to runaway registry bloat. But I'm not sure where to
even look to find out.

I looked at some registry "compaction" tools, which appear to be little more
than defragmenters. They show that most of the space actually does contain
data. Well, I have to blow all the unnecessary stuff away and if it's got
anything to do with COM I'm out of my realm of expertise. Could someone help
me with this one?

TIA,
Bob

 

[Ray Cassick \(Home\)]

My exported registry is 68.4 meg.. so, whats wrong with the size?

 

[Guest]

Two questions:

What causes so large a registry

Doesn't a large registry slow down loading programs using registered DLL's and/or data stored in the registry? Wouldn't the search time to find these things increase with the number of registry entries?

 

[Ray Cassick \(Home\)]

I guess things might be delayed a bit when the registry gets large.. but I
can't believe that when something needs to be found that the entire registry
has to be searched through to get at it. It seems to me that there has to be
some type of indexing scheme.

Two questions:

What causes so large a registry

Doesn't a large registry slow down loading programs using registered DLL's

and/or data stored in the registry? Wouldn't the search time to find these
things increase with the number of registry entries?

 

[Bob]

And there's my argument for using a real, if stripped-down, relational
database for the registry instead of a flatfile. But I hear they're
experimenting with that in Longhorn.

My information is apparently dated. Last time I paid attention to total
registry size 14MB was a little big. Nearly 70 megs is normal? That just
blows my mind. Guess I don't need to worry about cleaning it up if that's
normal.

Bob