Hi all,

I'm back to ask for some (more) advice.

We are about to start to write a Windows GUI program, to interface with
our D3 system, that we provide to clients.

I've been trying to read through information on the web about various
..NET languages, and am finding it hard to find exactly what I need to know.

At the moment, we are leaning towards using VB.NET with PDP to create
the new software. However, these are the questions which I need to answer:

1. What MS development kit do we need to use? Would VB.NET be enough, or
do we need to install all of Visual Studio (which I believe is
significantly more costly, and also a pretty large installation)?

2. How easy is distribution of software written in VB.NET using PDP? Are
VB runtime libraries required?

Thanks in advance for any help you can offer me,

Michael Nelson
Softec Ltd

Michael Nelson wrote:
if you have not already done so. I believe it to be worth the effort
even though I have not had an opportunity to put it into use yet.

Ron White


http://www.newsfeeds.com The #1 Newsgroup Service in the World! 120,000+ Newsgroups
----= East and West-Coast Server Farms - Total Privacy via Encryption =----

Michael Nelson wrote:

Not trying to offend here, but your questions appear so basic that I
question the odds of success.

A couple of questions that come to mind:

1) Why do you believe that a .Net solution is appropriate?

2) If in-house expertise is not available, why not contract the work to
another developer?

Maybe I'm totally off base here and this is a relatively simple project
that's being used to launch your move into the world of .Net
development. If so, then I'm glad to see a MV developer moving forward
with at least some type of "newer" technology.

--
Kevin Powick

Michael Nelson <michael (AT) REMOVETHISsoftecltd (DOT) com> wrote:

Any time - welcome to the forum!
Like many Pick developers you're starting from scratch with this GUI
stuff, and there are right ways and wrong ways to approach it. What
most Pick people don't appreciate is that .NET is not just peripheral
to some plan to build a GUI. The choice of language or communications
components is almost trivial to the real challenge. .NET is an
implementation of a grand specification. It would help for you to
understand something about that larger plan before diving into code.
The decision to use .NET should be based upon the plan, not based upon
your ability to write code - as Kevin said, why is .NET appropriate?
If you're approaching the project as "I think I want to use PDP, so I
need to use .NET", then your project is headed for disaster.

I spend a lot of time in book stores and they're good for this sort of
research. Pick up a book on Beginning VB.NET or a Fundamental .NET
Framework sort of book, relax with some coffee, and go through the
first few chapters. Focus less on syntax and more on the general
theme. Focus especially on object orientation, classes, inheritence,
overloaded methods, and accessors vs properties. Get an idea of the
components of the Framework: the Base Class Library, data typing,
ASP.NET, ADO.NET, remoting, XML, WinForms, threading, serialization,
assemblies... I'm not suggesting you study them or become an expert,
just understand them because many of these components are critical to
development. Now pick up a C# book and look for the same topics -
you'll notice that it's all the same, which is one of the big benefits
of .NET. If you like Java or JavaScript, maybe C# will speak louder
to your sense of elegance than VB.NET. If you're real daring, buy a
book - it will be good for you and will ensure that the book store is
there next week for your continued research.

Something else you're facing now is that we're on the cusp of
converting from .NET Framework v1.1 to 2.0 and a lot of things are
changing (generally for the better). A v1.1 book will be a good start
but be prepared for VS 2005 where some of those rules won't apply
anymore. (Uh oh, I hear the stomping of anti-MS pundits for that
one.)

Ron suggested taking a look at mv.NET and I'll agree. I've used both
PDP.NET and mv.NET, and while I am happy to use both, and will even
sell either product along with development services, my personal
preference is for mv.NET. My recommendation for any given site would
depend on their needs, not my convenience, but I do recommend that
prospects consider both options.

The difference in cost is probably a couple hundred dollars. Follow
this link for free information and downloads:
http://msdn.microsoft.com/vbasic/ Or join the Microsoft Partner
program and get all the development tools you need for a couple
hundred dollars. If you're developing thin-client browser apps then
there are free tools here:
http://www.asp.net/webmatrix/default...dex=4&tabId=46

Large installation? My Visual Studio 6 (Enterprise) consumes at least
200MB and Visual Studio .NET 2003 (Enterprise Architect) consumes at
least 700MB. My MSDN Library (partial install, not required) consumes
430MB. Disk is cheap bud, this shouldn't be a consideration, and if
it is then your company isn't providing you with the resources you
need for development.


You need to allocate D3 licenses and install an account into D3. This
shouldn't be a major deal, but you need to ensure that you architect
your application to consume as few licenses as possible. This is a
frequently discussed topic in this forum and your research should
include some time in Google Groups looking for threads on this topic.

Installation of these technolgies involves some code on a middle-tier
server, which might be your web server, maybe some UI code, and almost
certainly some server-side BASIC code.

How you write your code is important, and I only mention this because
it affects how you design your code ahead of time and where you put
components (oh yes, code should be designed before it's written...).
Most people write VB or VB.NET code just like they write Pick BASIC:
PRINT "NAME":
INPUT NAME
READ PERSON FROM F.PEOPLE,NAME ....
With object oriented code you want to divorce the data access layer as
much as possible from the UI - always ask yourself some key questions:
- Is the UI at all dependent on the component that accesses the data?
- Is there any code in the server that ties directly to the UI?
- Are there business rules in the UI?
- Is the connectivity code to the database exposed by the business
layer?
If you answer yes to any of these questions then the code isn't
written properly. If you can replace ODBC with PDP.NET or PDP.NET
with mv.NET or mv.NET with an interface to MySQL - all without
changint your rules or UI, then you've properly divorced the data
access layer. If you can switch your rules from WinForms to ASP.NET
web pages or UI-less Web Services, then you've properly divorced the
rules from the UI.

I really think you need to discuss your business objectives with
someone who can mentor your development from a distance. If you
develop a GUI front-end for your clients as a learning process, it
will look like a front-end that has been developed as a learning
process - and might not help to meet your business objectives. So you
might consider getting some assistance there too.

If you do choose a tool for communications like PDP.NET or mv.NET, be
aware that these tools are built upon the .NET framework, and require
knowledge of the .NET framework to use. You can't just buy a tool and
expect it to somehow mask the mystery of the technology for you. It's
like getting a car for someone without a driver's license or any
experience behind the wheel.

I'll be happy to provide consultation, tools, mentoring, and
development assistance as part of a plan to accomplish your goals.
But if you're concerned about the cost of VS or disk space I don't
know if that offer will do you any good.

HTH, and Good luck whatever you do,
Tony Gravagno
Nebula Research and Development
TG@ removethisNebula-RnD
..com

Tech Editor, C#Builder KickStart, SAMS Publishing
Tech Editor for C#-related articles in various .NET magazines
Author, "Web Services and .NET" series, Spectrum Magazine
Former RD manager, and a sordid past that we won't talk about...

Thank you all for your time.

I wrote a detailed response two days ago, but when my connection to the
server failed, Thunderbird chose to shut the message without saving it.

I just don't have time to retype my message at the moment, and for that
I apologise. I'll have to get back to you later.

Thanks again,

Michael Nelson
Softec Ltd

Hi Michael,

Firstly, Visual Studio is the product you need as the basic VB.NET doesn't
include all the installation utilities and this will make roll-out more
difficult than it should be.

Secondly, within your project, you create an installation project (using
Wizards) which generates the correct MSI file. This file distributes all the
necessary libraries with the exception of the .net framework which should be
loaded separately.

Regards


Jon Dempsey
YMA Associates Ltd
"Michael Nelson" <michael (AT) REMOVETHISsoftecltd (DOT) com> wrote

Jon, you're right that wizards help a lot, but I've heard that the VS
2003 installation wizard has problems which MS did a lot of work in
VS2005 to fix. I can't speak from experience, I'm using an old
InstallShield Express which gets the job done for me, especially since
I still do a lot of VB6 work too. I was going to upgrade ISE but I
figure I'll try the VS2005 improvements when it goes production and if
that does the trick I won't go through the expense of buying a new IS.

Also, for many purposes, the XCopy deployment makes installation as
easy as just dumping files on someone's system. I understand that
doesn't manage GAC registration and the needs of larger projects. I'm
just saying for beginners who are deploying simple projects, an
installation project might be overkill.

I'm really not on either side of the fence here. What do you think?

T

"Jon Dempsey" <jon.dempsey (AT) talk21 (DOT) com> wrote:

Tony:

A few additional comments to your excellent review:

"Tony Gravagno" <g6q3x9lu53001 (AT) sneakemail (DOT) com.invalid> wrote


[snipped]

This is probably fundamental. Most of the recent development environments
require multiple people to build the solution; thus planning is critical if
for no other reason than to delegate development responsibilities.

[snipped]

This is not so much logical differentiation as it is technical
differentiation and is the bane modern development. If one thinks in
logical terms, learned from other disciplines, and assumes that development
issues can be resolved by applying these basic logical principles then one
is in for a huge surprise. A lot of this kind of development is done the
way it is because that's just the way it is and only experience helps. So,
don't expect to grasp the logical flow of modern development in any detail;
just recognize that development needs more human resources than an
Pick-style environment.

[snipped]

There is an ISV program for small independent developers that costs about
$400 / year for up to two years. You can review it at:

http://msdn.microsoft.com/isv/default.aspx

and check out the Partner Program.

VS 2005 and SQL Server 2005, along with MSDN take severl gigabytes! Yes,
that's right. You need a pretty powerful machine to run this stuff. But
hey, we're all supposed to own development machines, right?

This is probably a primary implementation issue that needs to be planned
for. Most mvDbms systems are ___VERY___ expensive and when you add on the
cost of the PDP.NET/mv.NET licensing scheme your solution will be way too
expensive to sell or implement unless you reduce licensing by moving to a
"non-persistent" connectivity model. This requires additional development
to code "state", where it was never required in the telnet connectivity
model.

[snipped]

A reasonably well written mvDbms application does a lot of this already.
Remember, it is not likely that your development will be replacing the
mvDbms with MySQL. Some applications, like PeopleSoft, will want to write
to multiple databases but that is not usual for most applications. However,
moving from ODBC to OleDB to ADO.NET. This is a good example of where you
will need outside human resources. This kind of code almost always requires
someone with experience to write. :-)

[snipped]

Hope this helps.

Bill

"Bill H" <notme (AT) bogus (DOT) com> wrote:
That point needs to be emphasized. I know a lot of intelligent people
who are picking up .NET with the attitude that it's just like VB6, or
"how hard can it be", or ".NET is just a buzzword, code is code, I'll
make it work". This is a major deal and hopping into this car without
knowing the brake pedal from the accellerator is definitely not
advised.


Well, SQL Server isn't required for .NET development. If you want to
noodle with a relational DBMS you can use MS Access, MSDE, or MySQL
among others - but the point is taken about major diskage.



Yes and no. A remote app that's written persistently like a
greenscreen app will be costly. But with mv.NET for example, you have
the ability for many users to share a logged-in connection even if the
app is written in a mostly-persistent manner. State can be managed on
the client, the middle-tier, or automatically by the server. Knowing
how to do this just requires a some reading and experimenting.


I'm hearing more and more from people who want to share MV data with
Oracle, SQL Server, and MS Access - or even with other MV
environments. This is just another reason why it's good to have some
experience with technology like .NET and tools like mv.NET and
PDP.NET.

T

I've never had too many issues with the .net installation wizard except for
the fact that it is very poorly documented. For basic (no pun intended!)
projects it does pretty much what it says on the tin.. . It's only when you
want to customise the installation process (eg adding registry keys, or
conditional installation etc) that it starts getting a little but of a
minefield - the minefield is mainly answering the "How do i's..." rather
than working round problems with the installation system.

Just my two cents worth.

Regards
Simon

"Tony Gravagno" <g6q3x9lu53001 (AT) sneakemail (DOT) com.invalid> wrote