Central code library in ASP.NET

Using ASP.NET and C#:
I have multiple web projects, on a server, inside a network, that all need to reference the same classes. Some of these methods will be database routines and need to be secure (e.g. record insert methods, whatever). What is the best way to go about this?

Web services seemed to accomplish this with code in a central place, but they are not secure for data operations and add bloat from what I understand, and are also more for use with disparate systems across the cloud, not so much for internal compatible .NET applications.

Class libraries seem to be a possible answer and I see simple tutorials on this on the web for console apps, but not for web applications (so far, I only did a cursory search). If I go this route, does each web application reference one piece of code in one place, or do they all make a copy when the library is referenced? If the latter, do I have to go update every single application every time I add a new class, method, etc or change an existing one?

Many thanks for the assistance.

devo00Asked:
Who is Participating?
 
quizwedgeConnect With a Mentor Commented:
Short of using an SSL certificate for your web services, I believe it would be.  My understanding of your question was that the web services would be either on the same server or on the same trusted network as the ASP.NET code.

Doesn't change anything for web applications.

The class will have to be in the same bin folder as each web application, so you'll need multiple copies of the file.  With the way I described, each Visual Studio solution will include the library project and you'll add a reference to that project instead of the DLL.  That way, when you recompile one of the apps you'll have the latest version.  It's important that your solutions all add the same files rather than just copying the project into each directory of each project.  If you use Visual SourceSafe, you just pull down the same library project from Visual SourceSafe.  So, you won't actually be connecting to the class on the web server when you're developing.  You'll have your local copy that will be a separate DLL that you upload to the web server.

As for having to recompile all apps, it really becomes a matter of company policy at that point.  In my mind, it would work best if you did recompile all projects whenever anyone makes a change that way you know that all of the DLL's are the same version.  That being said, if you make a change to the library (change a method, add a method, etc.) and app "A" doesn't use that method at all, since each app has its own copy of the library, you wouldn't have to recompile "A".  In theory, not recompiling "A" would work perfectly since when you went to work on app "A" you would have the latest library code in the project and would just have to remember to upload not only the DLL for "A" but also the DLL for the library.  I just tend to be a little paranoid and worried about multiple versions of the same library floating around. :)

The other option that I thought of is that you could create a DLL and register it on the server, but then I think you would have to recompile all of the applications each time and it just seems like more work.

Sorry for the ramble... I'll try to summarize:

You have apps "A", "B", and "C".  You also have a project "Library".  "A", "B", and "C" all reference the project (not the DLL) "Library".  When you compile, for example, "A", you'll have the dll for "A" and the dll for "Library" in the bin folder that you'll want to upload into the bin folder on your web server.  If, while working on "A", you add method foo() to "Library", you can recompile "A" and upload "A".dll and "Library".dll to the web server.  Since "B" and "C" don't use this brand new method, you don't have to recompile them, just realize that "Library".dll in the bin folder of "B" and "C" will not be the same.  You then later go to work on "B" and want to use foo().  Since your solution for "B" also has the project "Library" in the solution, you've got the latest code which includes foo().  You update "B", recompile, and upload "B".dll and "Library".dll to the bin folder of "B" on the web server.  Now "A" and "B" both have the version of "Library" that uses foo() and "C" does not.

Does that make sense?  Running on a big lack of sleep, so if it doesn't, feel free to ask for clarification. :)
0
 
rashmi_vaghelaCommented:
0
 
quizwedgeCommented:
You could go the web service route and require a "password" parameter to help secure it, but web services seem to slow things down in web apps (at least in my experience).

My thought is that you have one Class library project.  Add that library project to all of your solutions.  That way, whenever you compile it will compile the latest version of the class project.  When you change the class library project, you'll have to recompile your other projects and upload each project to their respective bin folders, but since you can set a reference to the project instead of just a DLL you won't have to remove the reference, copy the DLL, and add the reference back in for each project.

Even if you went the web service route, you would still have the update the reference in each project whenever you updated the web service.
0
Never miss a deadline with monday.com

The revolutionary project management tool is here!   Plan visually with a single glance and make sure your projects get done.

 
devo00Author Commented:
Thanks for your input!
I agree, we have learned that web services are inappropriate for this situation. -Even if they asked for a password, that would be transmitted in the clear I believe, not to mention the extra size / conversion time when data is changed to / from XML.
So:
- Our uses are mostly for web applications, does that change anything?
- When I add the reference prior to publication and the class sits on the web server, can I still point / browse to it?
- Do I have to recompile all apps when any change is made to the library (new methods, etc), or only when methods used by a specific web app are updated? (With web services the latter is the case I believe.)
Thank you!

0
 
devo00Author Commented:
Extremely helpful, thank you! I'm sure I'll have additional questions if you don't mind.
0
 
quizwedgeCommented:
Thanks for the points.  I don't mind follow up questions.
0
 
devo00Author Commented:
Thanks I had to figure out that only console, libraries or windows apps can be a 'project'. All my items so far are web sites that apparently each sit under a solution. I did see where you could reference a project rather than the DLL, but my list was empty (all web sites so far).

So will I have to re-reference the library every time I compile the web code as I did with web services?

Get some sleep! :)

0
 
quizwedgeCommented:
Shoot... I just realized something.  When I do ASP.NET development I use the "web application" template which allows for more than one project in a solution.  You're probably using the website template.  Here is an article on the difference between "web applications" and websites: http://vishaljoshi.blogspot.com/2009/08/web-application-project-vs-web-site.html  Would you be opposed to switching to a web application project?  Instructions to convert can be found at http://webproject.scottgu.com/CSharp/Migration2/Migration2.aspx

If you can't / don't want to, I don't think my solution will work because website projects don't appear to allow more than one project to load at a time.  Web application projects allow multiple projects as part of a solution.

If you do need to keep it as a website, I think the best you can do is have a library project and then on each of your websites browse for the DLL in the bin folder of the library project.  You'll have to compile your library project first.  In theory, when you compile your website, it may grab whatever is the latest compiled version of the DLL.  I'm not sure on that though, so you may want to check it with some small test code before you go fully forward with this idea.

Sorry... I'm so used to using web application projects that I forget there is a website project.
0
 
devo00Author Commented:
Hey thanks for the links! (I know your job is done. :)

Hmm, I'm not sure, I usually just say 'New Web SIte', then an 'ASP.NET Web Site' template, which ends up under a new default solution of some sort. The Project / web site / solution relationship seems nebulous to me still.....

I use a C# AJAX enabled template, at work and the attached screenshots don't show that, but you get the idea.

-I guess you select 'New Project', then 'ASP.NET Web Application' template? Should I be doing this for web applications?

Thanks again, this is very helpful!

new-web-site.png
0
 
devo00Author Commented:
Sorry, missed the second attachment.
web-site-template.png
0
 
quizwedgeCommented:
That's correct.  Instead of New Website, you choose New Project and then ASP.NET Web Application.  I like the Web Application project type, but then that's what I started with and I typically build web software instead of web sites.  I can see the benefits of the Web Site project type, but it seems like for anything that needs more advance behind the scenes stuff (such as a shared class like you're looking to do) that the Web Application lends itself better.

A project holds one or more files and lets Visual Studio know what files are part of your web site / web application / windows application / etc.  A solution holds one or more projects.  So, if you're building a web site project you'll have a solution that has one web site project and doesn't appear to be able to have any more projects.  If you're building a web application project, you'll have a solution that starts out with one project, but you can add others such as the shared code mentioned above.

Hopefully that clears things up.  Feel free to ask if you need anything clarified.
0
 
devo00Author Commented:
Excellent, thank you again for taking the time to expand on all of this! (I hope you got some sleep, have a great weekend!)
0
All Courses

From novice to tech pro — start learning today.