Our applications has 1 set of users that are located in a "user" catalog. Then each application has its own catalog. Each application will have a LLBLGen project assigned to it, but we want them all to share the DBSpecific Assembly. I have found the item that turns off the assembly generation, but it appears to have information that is specific to the classes. I would like to get this moved in with the Class Assembly. Currently, I will have to include a min of 2 DBSpecific Assemblies in each application Assembly.

VS2005, C# Adapter Template.

I'm not really following what you want. The user catalog, that's solely used for user-related stuff? so you have 1 project created with that catalog? If so, can't you just generate the code for that project and reference the assemblies compiled from that catalog in your main application?

User Login has 2 Assemblies (Security.dll, Security.DBSpecific) 1 catalog Events has 2 Assemblies (Events.dll, Events.DBSpecific) > 1 catalog Gifts has 2 Assemblies (Gifts.dll, Gifts.DBSpecific) > 1 catalog The DBSpecific DLLs all reference SQLSever. User Assemblies reference a single catalog. Event and Gifts catalog references are set at login.

Ex. User logges into Security and rights are given to Event System A and Gifts System C.

All this redirecting works as expected. The issue we have is that we would like to have 1 DBSpecific Assembly not 1 per System. This does not seem to be possible because there is specific information in each DLL that references the schema (ex. PersistenceInfoProvider.cs).

I have some code that manages the existence of an Adapter based on its connection string. This is done so an adapter only gets created once per page request. If each Assembly has its own Adapter I will need to create the management in each assembly.

You could create a project with all catalogs in 1 project in LLBLGen Pro, as you can add multiple catalogs to one project. I'm not sure how big your project is, but it might be that this is usable in your situation.

Each non-System project changes on its own schedule, so putting them all in one would be more make it harder to release them at these times. I have made some changes so that the DatabaseSpecific code is generated in a folder inside the other Assembly. This gives us 1 assembly per project which is better for now. A couple of things I noticed when I generated the assembly this way.

• App.Config is in the folder.
• SD.LLBLGen.Pro.DQE.SqlServer.NET20 was not added to references
• System.EnterpriseServices was not added to references
• AssemblyInfo.cs was generated twice. (In root and subfolder).

Your thoughts on doing it this way?

I don't know which changes you've made. It can be you forgot to update a folder specification here and there, is that correct? LLBLGen Pro vs.net project task performer alters an existing project file if it's already there. So you need to generate that one just once.