PDA

View Full Version : Centralizing Code


voxecho
01-26-2009, 08:19 PM
Hello

I am really new to ASP.NET though i've been writing ASP for years. Over the years i ahve created a number of libraries to accomplish different tasks; both function libraries and object libraries...

the nice thing about these is all i have to do is expose a central virtual include to these files and they are all available to use with a simple include statement.

now that i am looking at ASP.NET i am seeing that custom user/web controls have to be moved directly into the project itself in order to be used. If this is the case, it really poses the problem of repeated and antiquated code over the coarse of years... is there no central place that i can put code and add it to all projects (like a .H folder in the path for C++ / or a Class folder in Flash) where the IDE will pick them up?

please advise.

-Echo

demtron
01-28-2009, 03:39 AM
You can try one of these:

1) compile your libraries into a dll, then put the dll in the /bin folder to make it accessible to the project

2) In .Net 2.0 or higher, put your class files into the /App_Code directory, which will make them accessible to the project. They will be compiled upon first access.

Hope that helps. Like you, i have a huge library of components that I regularly need to distribute.

voxecho
01-29-2009, 03:01 AM
actually, the things you suggest are the very things i was trying to avoid *mutter* - i was hoping for something that would allow me *not* to have to copy files for each site/project that would use them.

well, if it's not possible i will curse MS and move on. thank you

demtron
01-29-2009, 04:39 AM
I was assuming that all your projects would be going on different servers - for example, if they are on shared hosting. If all your projects are on the same server, the DLLs could be added to the global assembly cache and accessed in all your projects from there. If your projects are spread across multiple servers on the same network, you could store your DLLs on one server and call them via XML web services, remoting, or add project references to the UNC paths of the DLLs. In short, XCOPY deployment, as my original suggestion is called, is not the only option.

Hope that helps.

voxecho
01-30-2009, 12:39 AM
well yes. again, i understand that route. the challenge with that is that a lot of what i am wanting to use are user controls (e.g. HTML type codes or things that need access to web form objects) which means that they can't really be put into the .dll type structure.

well, they can, but it means alot of response.write and a lot of converting things for use.

anyway, thanks for the help