question about best practices

[Karl Hungus]

Ive been trying to get an answer on this for a while but I can't seem to get
a clear answer.

If I want to use external c# classes, accessed from my codebehind page, what
is the best way to set that up?

Currently I have the following setup.

-Shared hosting that supports asp.net
-Im placing assembly DLL's I created from my c# classes in my bin directory.
One per *file* currently. In otherwords, one file can have several classes
in it, although all are in the same namespace.

I would like to have one class per file, as in Java.

Question: Should I compile each class into its own assembly, or is there a
better way. E.G. - multifile assembly, or...?

TIA
Karl
--
you know when you think you know something
and then you realize you know nothing

[Rasika Wijayaratne]

I've found that Visual Studio's way of organising classes and DLLs is quite good. From your post I assume you have not used VS before. This is how you would replicate the same structures. Have your root folder, and have sub forlders for each unique 'Project' or Module of your application. Put all your classes as individual files (one file per class) in each relevant sub-directory.

Visual Studio creates an assembley DLL per 'Project' or module and puts it in a sub-directory called 'bin' under the owning module sub-directory, i.e.:

RootFolder\Module1\bin\Module1Assembley.dll
RootFolder\Module2\bin\Module2Assembley.dll

This seems a logical way to do things as usually a single 'Project' or module usually represents a single 'Business Unit', if I can call it that; a logically related set of classes. This way you can re-use the the assembley DLLs in other applications if required. This is can be done if you don't have Visual Studio.

Or better yet just get Visual Studio :)

Rasika Wijayaratne

[Karl Hungus]

"Rasika Wijayaratne" <ra**********@luckymail.com> wrote in message
news:22**********************************@microsof t.com...

I've found that Visual Studio's way of organising classes and DLLs is quite good. From your post I assume you have not used VS before. This is how
you would replicate the same structures. Have your root folder, and have sub
forlders for each unique 'Project' or Module of your application. Put all
your classes as individual files (one file per class) in each relevant
sub-directory.
Visual Studio creates an assembley DLL per 'Project' or module and puts it in a sub-directory called 'bin' under the owning module sub-directory, i.e.:
RootFolder\Module1\bin\Module1Assembley.dll
RootFolder\Module2\bin\Module2Assembley.dll

This seems a logical way to do things as usually a single 'Project' or module usually represents a single 'Business Unit', if I can call it that; a
logically related set of classes. This way you can re-use the the assembley
DLLs in other applications if required. This is can be done if you don't
have Visual Studio.
Or better yet just get Visual Studio :)

Rasika Wijayaratne

Thanks, I actually looked at the iBuySpy application example and found the
batch script to compile all the classes into one dll. Same thing you said
basically, but I needed a command line example. If anyone's interested mine
looked like this:

csc /t:library /out:SiteLib.dll SiteController.cs PostBackReceiver.cs
FileManager.cs XMLEditor.cs MenuCommand.cs XPathUtil.cs

As a side question, I would like to get visual studio. Whats your opinion on
getting it as an msdn subscription, or buying it alone.

TIA
Karl

[Rasika Wijayaratne]

Standard edition is fine for general development (about USD100). It has great support for winforms and webfroms apps and the rest of the apps supported by other editions. The startup projects are just code skeletons after all, so you can do pretty much any project type with standard editions, even once that are not in the New dialog (i.e. your own project types)

However .NET Compact Framewrok is only available with Professional ed and above. Also don't know if DirectX (managed) will work with standard ed

Rasika Wijayaratne