Deploying compiled Class File (dll) for website

[Andrew]

Hi all,

I am still learning ASP.Net, and .Net in general. Though I feel I have much
of the "basics" down, I am running into some gray areas in more advanced
topics. My question is how I make sure that a class file (DLL) I wrote and
am using (via "Add Reference") on my development webserver still works
correctly when I copy all my files over to the production server. Do I need
to create the same folders on the production server as on the development
server and place the DLL there? Do I simply place the DLL on the production
server and .Net will find it? What I am trying to get at is under "classic"
ASP, I could simply do a REGSVR32 on the DLL and all my ASP apps could see
it. I would simply unreg and re-reg a newer version of the DLL and all was
updated. Now with .Net, if I need to use a .Net class file (DLL), how do
I/should I use it on the development server compared to the production
server so that once written and compiled that DLL is available to all
ASP.Net apps, but also that I can update that .Net DLL.

I hope I am making my question understandable. The whole point here is that
I want to use a DLL as my "business logic" layer rather than write the same
functions over and over in all my ASP.Net apps, and then run into problems
when I need to update those functions. By using a class file (DLL) I can
simply use my functions/methods from a common, central, location.

I look forward to your input, suggestions, and/or advice. Thanks in
advance!

-- Andrew

 

[Kevin Spencer]

Believe it or not, this is not an advanced topic, but a fundamental one.
..Net and COIM are completely different technologies, and work entirely
differently. COM DLLs and classes are registered in the System Registry,
where the location of the DLL is stored as well. .Net assemblies (DLLs) are
located by their location relative to the application using them, and are
usually located in a folder named "bin" directly under the application root
folder. .Net assemblies can also be registered in the Global Assembly Cache
(GAC), which works much like the System Registry for COM, meaning that any
..Net application can find them in the GAC. In essence, a .Net application
will search for the DLL in the bin folder, check the config files for other
locations under the bin folder, and also check the GAC.

Considering your level of expertise, your best bet would be to use the bin
folder, and simply copy your DLL to the bin folder under your deployed
application's root folder. You can use the same DLL in multiple ASP.Net apps
by making copies of it and placing them in the bin folders of each app.

--
HTH,
Kevin Spencer
..Net Developer
Microsoft MVP
Big things are made up
of lots of little things.

 

[Phill. W]

.. . .

You can use the same DLL in multiple ASP.Net apps by making
copies of it and placing them in the bin folders of each app.

Kevin,

Yes, indeed, you /can/ ...

I leave you to enjoy the "fun" that comes of trying make a change
to your "shared" assembly... just /which/ "version" is any given
application running? ;-)

Regards,
Phill W.
.. . .

 

[Andrew]

Kevin,

I really appreciate the input here, and in doing so were able to answer
a couple smaller side questions I had runnin' round the brain. However, and
you are correct in my experience level, I can't help but see problems with
your suggested course of action....
I am writing a class file (using the VB.Net Class Library project) to
write a few classes that help with mundane tasks such as making database
connections, returning records, cleaning up strings, various extended
date/time arithmetic, pixels per text character, etc, so forth, and so on.
Now I could indeed place a copy of the compiled DLL in the ASP.Net app that
needs it. However, I am already at 40 web apps and counting, not to mention
any helper "background" applications that may run on the webserver also
needing the DLL. If I use a separate copy in each one, and I make an update
to the DLL, and if I miss just one... I certainly do not have any desire to
spend my time double-checking each and every copy out there for version
integrity. (Which I believe is what the other responder, Phil W. mentioned)
So, if you (or any others reading this) can help me understand how to
use DLLs in a way where all applications on a single server all use the
*same* copy of the DLL, I would be most appreciative.
Again, thank you for the help, but your suggestion is really what I am
trying to avoid.

-- Andrew