Not quite sure, but this might point you in the right direction....

As far as I know the answer is no... but, you may be able to work around it by running the application remotely, which may require some hoop jumping. DLLs need to be registered, so unless they are on the server and registered there, you'll have to try some remoting type tricks.

Hope that helps a bit.

It can be done as in .NET you no longer need to register DLL's.

Okay thanks, I will look into remoting.

Looking around Visual Studio.NET I noticed something about adding 'Web References'.  It sounds like it might be a way of putting dll's on a web server so they can be referenced via http.  So I will also look into that.  Anyone here know anything about it?

That would be a web service.  IT basically allows a component to be made available through HTTP and can be called as per normal.

Try and get away from DLL's. They're not needed any more.

Check out: http://www.learnvisualstudio.net - http://www.learnvisualstudio.net   Excellent site and you can learn a lot.

Cheers,
Andrew

Hmm, the only thing on that site that can be accessed free is a video about threading.  And even that had to be signed up for.

As for you getting away from dlls, what is used instead?  Are these web services not dlls?  It seems to me that it is good practise to keep code in one place rather than have multiple copies of it all over the place, so that all applications can be updated by a single change.

For free, you get a video each week, plus the daily tip which you can watch on the site. If you like these, and can part with a few bucks then you get ALL the videos he's ever made, which are excellent. The best method I've found to learn about .Net and VS.Net.

Here are some free sites that have heaps of information on how the framework operates:
http://www.asp.net - http://www.asp.net
http://www.gotdotnet.com - http://www.gotdotnet.com
http://aspnet.4guysfromrolla.com/ - http://aspnet.4guysfromrolla.com/
http://www.codeguru.com - http://www.codeguru.com
http://msdn.microsoft.com/library/default.asp?url=/nhp/Default.asp?contentid=28000519 - http://msdn.microsoft.com/library/default.asp?url=/nhp/Default.asp?contentid=28000519

You're right that keeping code 'componentised' is a good idea, its just that dll's have sort of been replaced by 'Assemblies' in .NET. No registration required, easily portable, and no versioning issues that we had with dll's (DLL HELL).  You can still use/create them as before if need be.

All they have to do is sit in a certain directory (GAC -> Global Assembly Cache) on the server and they are useable!

Hope this helps!

Cheers,
Andrew

Bingo!  Here's an article on what I was trying to say:
http://www.4guysfromrolla.com/webtech/112101-1.shtml - http://www.4guysfromrolla.com/webtech/112101-1.shtml

There's also auto-deployment for stand-alone apps:
http://www.4guysfromrolla.com/webtech/121201-1.shtml - http://www.4guysfromrolla.com/webtech/121201-1.shtml

(They explain it alot better than me!!)

Sorry for ranting, as for your particular issue, web services are probably the way to go.

If you convert your components to a web-service, then any applications can access them through HTTP:
http://aspnet.4guysfromrolla.com/articles/062602-1.aspx - http://aspnet.4guysfromrolla.com/articles/062602-1.aspx

Remoting is also a possibility:
http://msdn.microsoft.com/library/default.asp?PP=/library/toc/cpref/cpref0-45.xml&tocPath=cpref0-45&URL=/library/dotnet/cpref/frlrfSystemRuntimeRemoting.htm - http://msdn.microsoft.com/library/default.asp?PP=/library/toc/cpref/cpref0-45.xml&tocPath=cpref0-45&URL=/library/dotnet/cpref/frlrfSystemRuntimeRemoting.htm

There are a couple of videos on LearnVisualStudo.net about remoting which are quite interesting, and explain how they work. Explains MarshallByRef (where the component runs on the host server) or MarshallByValue (component runs on the client)

It depends on exactly what you want to do with your components, who you want to make them available to, in what type of applications etc.

Okay, thanks for the info.  I'm sure the videos are great, but I only work part time here, and so I really only have time to look at things directly relevent to the problem at hand.  Also I'm not prepared to invest my personal funds on a work related project, I come here to earn money, not to spend it.

I am currently investigating remoting, and if that doesn't work I'll try web services.

I thought I was using assemblies.  They just seem to have 'dll' extensions, which is why I called them dlls.  Should .net assemblies have different extensions? 

Basically, an example of what I am trying to do, is the database assembly.  This is an assembly that sits on a server with Oracle Client installed, and when called, creates a connection to one of several different database servers we have here.  This mainly gets called by the intranet asp.net application that sits on the same server.

However, there is also another asp.net application that sits on a different server.  This also connects to the same databases, so should use the same assembly.

Also, it is possible that some windows applications may be written that sit on various client machines, that should also reference the same assembly.  This could be especially useful because Oracle Client would not need to be installed on each machine, just the server.

The same thing would apply to other assemblies...

Yep sorry. I was probably confusing things. They do have the same extension but are different from what we generally refer to as DLL's that must be registered by the OS.

Probably best we call them components!  Makes it a lot clearer..

As for your question, Remoting is a possibilty, however for the Oracle situation, you're adding another 'path' that the data must travel. ie From DB Server -> 'Central' server (which hosts your components) -> to local Server -> Client.

I'd imagine it would be more efficient for the data to skip the 'Central' Server in this situation, which would probably require you copying the components to each server.

Thats the advantage with 'assemblies' in .NET though. All you have to do is copy them to the \bin directory of your Web app (or the global assembly cache) and they're instanty available. No registering! 

Plus you'd think that once your component has been tested and finalised that it wouldn't need to be altered often? Additionally, doesn't .NET have a built in Oracle driver??

Anyway, there is another possible solution. There is a method in .NET where the client automatically downloads the application / components / classes upon request, which ensures the latest version (I think!)

I've read a bit about it and will try and find some more info. Get back to ya soon.

Cheers,
A

Okay, I have successfully run some tests for both Remoting and Web Services.  I think that Web Services seem a lot cleaner to use than Remoting, although it should be easy enough to just create a Web Services layer that allows access to certain classes to existing classes with the assemblies.

That way the main Intranet application will be able to run directly from the assemblies in its bin, whilst also offering bits of those assemblies to other secondary applications via some Web Services.

As for Oracle drivers, there isn't one with the basic distribution of .Net but MicroSoft have made one available.  I am of course using this, but what I call my Database assembly for accessing our Oracle Databases is higher level code than this.

As for registering dlls etc.  All sounds good although I have no idea what problems there were before because I am an ASP programmer that has only just started using assemblies now we are upgrading to ASP.Net and C#.  That .Net means we can use the same code to write Windows Applications is just something that has opened up possibilities.