Microsoft Application Blocks for .NET 2.0 VB Version???

[lds]

I am in the process of trying to migrate some of our existing .NET
applications from version 1.1 to 2.0.

In our 1.1 apps we have a common assembly that uses the sqlhelper.vb
class from the Micosoft Application Block provided for version 1.1.

When I try to migrate I get a few errors, so I thought that maybe I
should just try using the new application block for version 2.0. I
downloaded the Enterprise Library and it is all C#. Is there a .VB
version of the new application blocks? Our company has a standard that
all of our apps have to be in VB so I cannot use a C# version.

If anyone can help, please let me know. I downloaded my copy of the
Enterprise Library from:

http://www.microsoft.com/downloads/...70-406B-4F2A-B723-97BA84AE80B5&displaylang=en

 

[bruce barker \(sqlwork.com\)]

all the enterprise blocks are written C# (though they come with both nunit
or msunit tests). they are compatiable with vb. you should treat them a a
third party control and not worry about the language.

-- bruce (sqlwork.com)

 

[lds]

Thanks for the information.

We do have them set up like third party controls anyway and our
developers dont even see the code, I guess I am just a little hesitant
because we do not have any C# resources here. I dont even know what
you mean by nunit or msunit tests.

 

[bruce barker \(sqlwork.com\)]

the enterprise group has gone to agile and test first design. this requires
writing unit tests for the code. the open source tool to run the unit test
is nunit, and if you have the enterprise version of studio, you can use the
ms version, whose main additional feature is unit test code coverage
analysis.

note: test first design usually leads to factory interface based design (to
make writing unit tests easier). as this model came from the java world
(nunit is the .net version of junit) the pool of developers using this are
most likely C# devs.

-- bruce (sqlwork.com)

 

[sloan]

My opinion is that when the Application Blocks first were being used, they
weren't matured enough, and sometimes you had to fix things.

(Do a google search for "Nasty Bug in the DAAB" for the DAAB 2.0 version)

However, the application blocks (or EnterpriseLibrary as they've come to be
known as) are popular enough and mature enough that you don't have to worry
as much about them.

It doesn't mean they're perfect, but so many people use them they're getting
lots of test cycles in.

I'd be less worried about them these days.

I'd prefer the time be spent making them better (features and bug wise),
then having 2 versions (vb.net and C#) for just the sake of having them.

...

 

[Michael D. Ober]

Don't worry about the enterprise library being written in C#. Other than
the C'ish syntax, C# 2.0 is easy for VB 2005 developers to read and
understand. Also, as other posters have pointed out, you can use the
enterprise libraries simply as if they were actually part of the dotNet
framework since they install as global assemblies. Just don't forget to
include them in your setup programs.

Mike Ober.