OOP-handicapped

Hi - I'm developing a site in VS2003. I have a number of files (for seperate apps) lumped into 1 project - but now I'm to the deployment stage and realize this isn't such a great idea. The apps use some common User Contols and .vb files that I created. Worked great when they were all under the same project. So...I am trying to seperate them - I created 1 new project called "Common" and would like to put all the multi-use stuff in there and the other apps will each be their own projects. How do I still reference the .vb and .ascx from seperate projects? Please HELP!!!

Thanks!!!!Make your common directory a virtual directory of EACH application. This will solve the ascx problem.
As for vb files, you should compile them into a separate assembly that you register to the GAC and reference from each project.
Does this help?
well, yes and no - yes because I'm sure that would work...no because I'm using Visual Studio.NET 2003 - Isn't the idea of solutions and projects suposed to be easy to share between projects? Have I missed this somewhere?
Sure, but the deployment of user controls to multiple applications is not directly supported by VS. But if you setup this web site architecture prior to deployment, and if you ascx project is distinct from the other projects, the deployment should be very simple from the second time.
As for GACed dlls, VS.NET can take care of the deployment for you entirely.
Ok, well in monkeying around - I found part of a solution...maybe - In Add Reference...there's a tab for Projects (ah-ha!) So I added the Common project as a reference, but now my page gets a Parser error on the<%@.Register statement for the user contols:
The virtual path '/Apps/Common/DateRange.ascx' maps to another application, which is not allowed

any ideas? or am I really stuck with setting up a virtual directory to point to it?
Hi,

I think my question is similar. Hope you can help...

I am building an intranet portal using ASP.NET and C#. The portal is conceptually inspired by IBS Portal but all of my code is my own. This portal will serve as an entry point for several different reports and applications all in ASP.NET which MUST share the same ASP.NET Forms Authentication model.

So, I have the guts of my portal (i.e the homepage, menu system and nifty little modules for the homepage) compiled into the main dll in the root bin for my portal solution. The additional applications will be initially loaded as modules using a construct similar to the way DesktopDefault.aspx injects modules into the page. Anyway, it is imperative that each application's/module's dll be seperate from the main portal so that each application can be updated, compiled and deployed without affecting a) the portal itself and b) other applications.

Currently each application is its own ASP.NET solution, so each app has its own dll. How do I integrate these apps into my portal's folder structure while keeping their dlls seperate from my main portal dll?

Thank you very much for any assistance you can provide. This one kind of crept up on me all of a sudden ;-)
I figured it out, thanks!
You should consider n-tier approach in your development.

Separate your application in at least 3 tiers - Data Access Tier, Business Logic Tier and Presentation Tier.

You can share Data Access Tier and Business Logic among your applications and develope separate presentation tiers for each application.

Data Access Tier and Business Logic Tier can be added to each solution as class library projects to each solution in VS.

I am using Data Access Tier generator developed by Frans Bouma (http://sd.nl/software/) to generate DAL.
It is free and very well documented.
Thanks Almir. I am using 3-tier OOP approach. I guess I am actually using 4-tier because I am using Microsoft.ApplicationBlocks.Data for my data access tasks. So much less code to write!

Instead of having to implement all the plumbing in my DAL class, it now comes down to the following:

public class PersonData
{
public SqlDataReader GetHeartRate
{
//SqlParameter Code

SqlDataReader dr = SqlHelper.ExecuteReader(connString,StoredProcName,parameters);
}
}

I'll check out your tool.

Thanks.
I did have a look at Microsoft application blocks data component.

However I prefer clean functionality separation between tiers.
In my opinion business logic tier should handle only business logic and there is no place for connection string or stored procedure parameters in business logic.

That part of application belongs to data access tier.

In the same way I would not place any part of business logic in stored procedure.

The tiers should act as black boxes stack on the top of each other exposing only what is absolutely necessary to the adjacent tier.
I've created a portal modeled after the IB portal. I have one aspx page that houses a maincontrol.ascx. The maincontrol.ascx reads a database to find out what other default controls(ie. header.ascx, footer.ascx, left.ascx(contains links to authorized controls based on global group membership), right.ascx(contains an active directory enabled login box), and center.ascx (used to load authorized controls from left.ascx). One of those authorized controls is used to upload new authorized controls. I upload the ascx file into the \controls folder. I upload the associated dll file for that control into the \bin directory.

This allows me to create controls in separate projects in VS2003 and upload them into the portal without ever having to recompile the site. I just upload the ascx file and the dll file into the proper folders. All the permissions for the controls are given by Nt Global groups matched with the ascx file in a database.

When asp.net attempts to load a control, it first looks in the Global assembly cache. If the class is not found in the GAC, it looks in the applications bin directory. You just need to put the compiled vb file (dll assembly) in the bin folder of the application to make the class available. Note the filename.vb must be compiled into a dll file.