|
-
May 17th, 2005, 03:06 AM
#1
.NET DLL Design question
This is a question about design architecture more than anything else.
We are developing ASP.NET web apps.
We have a project called WebStuff.
In here goes code for JScript, Server side controls, page base classes blah blah.
The server side controls and jscript are generic for any web apps, while the page base class is not and is tied directly to OUR intranet portal app.
I believe that this one huge project should be split into many smaller versions. Server side controls, JScript etc and an intranet related dll.
I have just been told this is a daft idea and everything should be in one large DLL. Am I missing something here regarding VB6 to .NET architecture??? 

Woka
-
May 17th, 2005, 03:32 AM
#2
Re: .NET DLL Design question
I agree with you (I'm in the mood for shocks today).
I'm thinking in terms of logic here, and if I were to be reusing certain parts of a web project of mine in other web projects I'd make sure they were all separated and in different assemblies. Reason: Not all web projects will be making use of all the features.
Now that I've given my opinion, can you explain a little more about how you've included your JScript and how you plan to work with it in new projects? If you think it's deviating from your point, start a new thread and explain it there.
-
May 17th, 2005, 04:07 AM
#3
Frenzied Member
Re: .NET DLL Design question
I agree as well! If it separated out then you can pick and choose components for different projects. Plus it'll be easier to maintain!
DJ
If I have been helpful please rate my post. If I haven't tell me!
-
May 17th, 2005, 04:08 AM
#4
Re: .NET DLL Design question
 Originally Posted by mendhak
Now that I've given my opinion, can you explain a little more about how you've included your JScript and how you plan to work with it in new projects? If you think it's deviating from your point, start a new thread and explain it there.
Not sure what you mean 
A contractor at work said that having multiple projects is bad as they get splattered over the server as if someone used a splatter gun. Also, apparently it becomes too hard to manage many projects....this goes against everything from VB6, and so I don't think this is the correct method either.
One other point. We have 2 DLLs. A.DLL, B.DLL and C.DLL.
I now have 2 projects. Project1 and Project2.
Project1 uses DLL A and B, while Project2 uses DLL A, B and C.
When compiled on my PC, or installed on another PC, I end up with all compiled code in the same folder:
C:\Project1\Project1.exe
C:\Project1\A.DLL
C:\Project1\B.DLL
and
C:\Project2\Project1.exe
C:\Project2\A.DLL
C:\Project2\B.DLL
C:\Project2\C.DLL
We have MANY different apps that use many different combinations of the DLLs. Every app has a copy of the DLL in it's own folder. So we have 30 apps on our server, we therefore have 30 copies of A.DLL on the server.
Apparently this is good...! 
What if there is a bug in SQL code in C.DLL.
I would have to replace 30 copies of it on the server, and not just one copy like when using VB6.
This to me is a HUGE design flaw for a large company with many apps, web and win32, which use the same DLLs.
What do you think?
Woka
-
May 17th, 2005, 05:12 AM
#5
Re: .NET DLL Design question
However, I am aware that you can use the GAC for a centralised location for DLLs. BUT if I install DLL v1.0.0123 and then install the DLL v1.0.0154 then the old apps will not use the new dll, but will continue to use the old one...is this right?
Woika
-
May 17th, 2005, 05:21 AM
#6
Re: .NET DLL Design question
First things first:
One other point. We have 2 DLLs. A.DLL, B.DLL and C.DLL.
That's three.
Now that the important stuff is out of the way:
 Originally Posted by Wokawidget
I now have 2 projects. Project1 and Project2.
Project1 uses DLL A and B, while Project2 uses DLL A, B and C.
When compiled on my PC, or installed on another PC, I end up with all compiled code in the same folder:
C:\Project1\Project1.exe
C:\Project1\A.DLL
C:\Project1\B.DLL
and
C:\Project2\Project1.exe
C:\Project2\A.DLL
C:\Project2\B.DLL
C:\Project2\C.DLL
We have MANY different apps that use many different combinations of the DLLs. Every app has a copy of the DLL in it's own folder. So we have 30 apps on our server, we therefore have 30 copies of A.DLL on the server.
Apparently this is good...!
Who told you that's good, and when he said so, did you ask for an explanation? I'm not disputing whether it's good or not, I'm asking you whether you verified it.
What if there is a bug in SQL code in C.DLL.
I would have to replace 30 copies of it on the server, and not just one copy like when using VB6.
This to me is a HUGE design flaw for a large company with many apps, web and win32, which use the same DLLs.
What do you think?
Woka
That's what the GAC is for.
-
May 17th, 2005, 05:21 AM
#7
Re: .NET DLL Design question
Moving on:
 Originally Posted by Wokawidget
However, I am aware that you can use the GAC for a centralised location for DLLs. BUT if I install DLL v1.0.0123 and then install the DLL v1.0.0154 then the old apps will not use the new dll, but will continue to use the old one...is this right?
Woika
For situations like these, you can create a publisher policy assembly. You can specify which version of the DLL should be used.
Google it, you'll see what I mean.
-
May 17th, 2005, 05:22 AM
#8
Re: .NET DLL Design question
And what I wanted to know from you was your inclusion of your javascript files/functions in your DLL. Want to know more about that.
Posting Permissions
- You may not post new threads
- You may not post replies
- You may not post attachments
- You may not edit your posts
-
Forum Rules
|
Click Here to Expand Forum to Full Width
|