«

Please pardon my completely lack of understanding on the topic.

I have a website I developed with another developer. We are both far
from experts in VB.NET and OOP. We developed the site WITHOUT VS.NET,
compiling vb.net code into a common dll in the bin directory off the
root of the website. That one vb code creates a namespace we import in
all of our ASP.NET code. Compiling was done fromt he command line use
vbc.exec.

The site works well enough.

Now, and please exuse any missuse of OOP terms, we'd like to move the
site to VS.NET and more importantly understand how such a site would
have been developed via VS.NET if a team of developers were building it
and wanted to share code. Some real NOOB type questions below.

1. Because I manually created a DLL, does this classify that as
unmanaged code?
2. In VS.NET, at a high level, how does one create public classes and
functions that ALWAYS available to other developers and applications?
3. We are using VS.NET 2005, I took my vb that compiled into a dll and
Created a new class library, and compiled it. The build seem to run
fine. The code starts like this:

Imports System.Data
Imports System.Data.SqlClient
Imports System.Collections
Public Class cjason1
Public Function fjason1(ByVal cmd As String) As DataSet

I took the namespace out of the code, but left the imports in, not sure
if that makes sense.

I closed all projects and started a new asp.net website to see I could
find my new class in the object explorer, but I can't.

4. Am I missing something above, and is this how .net developers share
classes? I'm sure I'm completely misguided.

5. How does team explorer, team projects and team foundation work into
what we *THINK* we are trying to do? Keep in mind we are trying to keep
things simple and cheap for starts.

I guess my very noobie question is "how do most shops deploy and manage
classes"

A HUGE THANKS IN ADVANCE TO ANYBODY THAT CAN CLEAR THIS UP FOR ME. I
REALLY DO APPRECIATE ANY HELP YOU CAN GIVE ME!!!!!!!

Greetings, fellow n00b.

1) No - .NET is managed code. Managed code is code with all the funky
..NET trickery like garbage collection wher you don't have to worry
about checking your boundaries and accidentally writing data into the
middle of your operating system. .NET is managed, old-skool C++ Win32
code is unmanaged.

see http://en.wikipedia.org/wiki/Managed_code

2) I'm not entirely sure what you mean by always... and in fact I think
I'm going to drop the numbering because the remaining questions all
fall into the same concept category.

Namespaces in .Net

Namespaces provide a neat way of organising your classes into discrete
blocks of related functionality. Additionally, they provide a way of
disambiguating class names.
For example: you have Class Foo residing under namespace CyberPine, and
you purchase a new Foo component from AcmeComponents. Your class is
CyberPine.Foo and theirs is AcmeComponents.Foo, and that obviously
makes life less confusing.

If your classes are in namespace CyberPine.CommonUtilities (for
example) you can use them from other code by importing them, just as
you import namespaces from System.

If you want to use an existing compiled DLL in your ASP.Net project
(bear with me, I've not used VS in quite a while) then you have to
right-click in the pane to the right (references? I forget) and add a
reference to that DLL, and the classes contained in that dll will then
display.

To keep things sane, I usually use
CompanyName.ProjectName.DiscreteBlock as my namespace for classes where
DiscreteBlock might be Pages, or Data, or BusinessClasses, or Core. If
I were to share those dlls, any .Net developer could import my DLL and
do (pardon any errors in my VB):

Imports CompanyName.ProjectName.Core

namespace OtherCompanyName.OtherProjectName.Pages
Public class MyPage inherits System.Web.UI.Page

and have access to my core utilities and helpers within that page
class. Does that make a little more sense?


If you want to keep things cheap and simple, I recommend getting a bug
tracking db (we use FogBugz at our shop) and installing Subversion and
TortoiseSVN, but then I'm not much of a fan of the MS dev tools.

Thank you! I was able to get everything working by referencing the DLL.

But I still wonder, using just the native VS.NET IDE (without any of
the Team tools), how would a busy shop with say 10+ developers working
on the same website/project organize their DLLs? Everybody working on
the same single vb source class library?doubt it, but If so, would'nt
that be messy with concurrent development issues?

If not, wouldn't there be DLLs all over the place, and how would other
developers know what's where without first referencing them?

Say, I'm assigned the task of creating a new page, and I know that page
is going to need a bunch of already developed business functions that
was developed by different groups in the team. Until I reference the
DLLs I won't see what namespaces, classes and functions are available.
And until I'm import the namespace, I can't use those classes.

I know I'm missing something, and I might just have more to do with who
and how projects are set up in VS.NET. I would think (from the little I
know about vs.net) that It would be great, from the minute you start
working on a project, all those project or company specific classes
should be available to you, without having to locate and reference
them.

I guess, as a noobie, I'm looking to hear about both typical and best
practices. If you walk into the busiest VS.NET shops, beyond looking at
paper standards and developer guides, how would you know what's where?

Thanks again!

> Everybody working on the same single vb source class library?doubt it, but If so, would'nt
> that be messy with concurrent development issues?

Not really, as I said, at our shop we use Subversion to keep code
maintainable. The latest version of the code is stored on the
repository, developers make changes, and those changes are committed to
the central codebase.

If a developer is going to make wide-sweeping changes that will cause
build-errors for other people, he sets up a new development branch and
the changes on that branch can later be merged back into the trunk.

> Until I reference the DLLs I won't see what namespaces, classes and functions are
> available. And until I'm import the namespace, I can't use those classes.

I don't really see the problem here, are you asking for the ability to
reach out with the tendrils of your mind and find code? Xml comments
provide a nice way of generating documentation for your code, and those
docs should also be under whatever source control you decide on. If you
just want a quick way of sharing information, lists of useful classes
etc. you could always set up an internal wiki.

>all those project or company specific classes should be available to you, without
> having to locate and reference them.

Well if you've got a project set up, and that project is stored so that
multiple people can access it, I'm 99% sure that the project file
stores details of referenced DLLs, so that walking on to a project, you
would have the canonical list of namespaces and classes when you opened
and built it.

Company specific DLLs, well if you're going to build libraries then put
them (guess what I'm going to say) into a code repository so that
people can get hold of them if they need them, and document them
properly. I'm not sure how the IDE is meant to guess which DLLs are
always referenced? Without referencing the DLL, the compiler can't do
its magic IL generating thing, and without importing namespaces, you're
back to ambiguous class names.

I think what you're missing is that everyone will work with their own
copy of the code, but the canonical copy will be stored centrally.
Provided you're using a decent source control system, ie. not Source
Safe, you shouldn't have too many problems.

Or am I failing to understand?