Re: Possible to distribute without dotnet framework?

Hello Alex ,

As i said before i love VB.Net i work with it since the early beta`s and use
it profesionally since it was called Visual studio .Net without a year
suffix
( the 2002 version ) . But i also see the stronger points of my also beloved
VB pre .Net .

"Alex Clark" <quanta@xxxxxxxxxxxxxxx> schreef in bericht
news:%23ZlVYlPrJHA.3700@xxxxxxxxxxxxxxxxxxxxxxx
Michael...

"Michel Posseth [MCP]" <MSDN@xxxxxxxxxxx> wrote in message
news:udVrh7LrJHA.2552@xxxxxxxxxxxxxxxxxxxxxxx

Unfortunatly this update is not listed as a required update , so you
have to explictly select this bloated install wich nobody does if he
isn`t aware of the existence of .Net , in a managed environment the
chance is even higher that the framework is not installed if the company
doesn not have anny .Net production apps .

True, but in a corporate environment the IT dept should at the very least
be aware of it, and if they're halfway competent they shouldn't have any
problems installing it. Large corps tend to have high speed internet
these days, which makes applying updates like that a doddle, and given the
fact that MS Update automatically checks to see if the update has been
installed, whether it needs service packs, does all the installing
hardwork for you etc, it's really not a big issue - personally I'd view
installing the VB6 runtime more of an issue for an IT dept. I've written
and sold desktop apps to companies which have regularly been distributed
across 50+ workstations, over 200 in at least once instance, and
deployment was never an issue. Training was always the real hurdle, but I
digress...


Well for the company`s i worked for it was a verry big issue to install a
framework of 500 mb on all computers just to get my software running
okay honestly needs to say that this is nowadays a lesser problem but i feel
that MS should have forced the installation of the framework through a
servicepack or something like that . Then i would never needed to have
those awfull discussions with the tech guys .


The "special runtime" of .Net is called the .Net framework
Up to 500 MB of available space may be required

Which is not specific to VB.NET. I think Cor was trying to point out that
VB, in its current form, doesn't require any runtime specific to it, it
shares the same runtime as many other languages that are used commercially
and heavily today.


Yes i am aware of what the framework is but fact is that you need the
framework to run your .Net app and that is 500 mb while VB6 has a runtime of
just
a few mb`s.

The chance that currently a VB6 exe will run DirectX, is low.

Why ? AFAIK you can use DirectX in VB6 so i do not get your point

I'm pretty sure you can't, at least not with newer versions. From what I
recall, special COM libraries had to be set up for VB6 to use it (as it
can't use the full range of COM the way C++ does for example), and
something tells me MS aren't interested in doing that with the latest
versions of DirectX. I'd be surprised if anything beyond DirectX 8 worked
with VB6, and even that is optimistic. Personally DirectX compatibility
would be the least of my problems if I was forced to devolve to VB6.


Well i can`t tell this from my own experience as i don`t use VB6 now for at
least three years
and ofcourse VB6 is dead now i don`t argue about that at all


Every standard program written in VB6 runs on a computer that has the VB6
runtime installed you can then even use XCopy deployment if you want .

Yep. Unless you need database access, then you have to make sure that the
correct version of MDAC is installed. Oh, and then you might have used
some nice Windows controls like tabstrips etc, so you need an OCX
installed for that, and a few others.


Yes , but i see nowadays already a lot of people using externall libs in
there progs ( crystal reports for instance )
so the same problem is introduced in .Net

My VB6 totall runtime CAB size including mdac was smaller as 10 MB

Then you realise you're writing a proper multi-tier app with business
logic partitioned into separate DLLs, which (because they're old style COM
DLLs) need registering. Then you find a bug in one, so you have to patch
it, unregister it on the client's machine, copy it, and re-register it.


I installed all my APP dll`s in the application path and switched binary
compatibility off , so i could just xcopy my dll
after one succesfull installation and registration


VB.NET? It's either all there, or it isn't. One install of the framework
and I'm ready to go.

If you do not use anny third party controls / tools this is righ, but the
same could be said forVB6
if you only use the standard controls in VB6 or just once installed these
tools it would work just as fine



VB6 deployment was hellish compared to .NET, and believe me I've had my
share of experience with it. XCopy a VB6 app? Not unless it's some tiny
little one-exe utility. Real world, serious business apps just aren't
built that way, and in VB6 there wasn't a chance you could XCopy them.


Right,,, ofcourse .Net is a giant leap forwards but if you have a good
setup you do not encounter so much problems with VB6
by the way i had a userbase of + 20.000 where end user received a cd-rom
and installed the software themselves on windows
9.X to XP and never encountered anny reall issues that couldn`t be
solved by telephone .



I was one of the petition signers to keep classic VB alive , as it is
still superior for deployment to end user computers
for the obvious reassons ( runtime size , and security of your
intelectual property )

You've defined two areas where, in your opinion, you find it superior.
"Intellectual Security" is a problem easily solved with obfuscation, and
those tools are now freely included in the latest version of VS.


Obfuscation , yes i tried that but it does exactly what it is called it
obfuscates it is lessa safe as you might think
with some simple free tools also availlable on the web i can reverse
engineer almost anny app or steall at least a lot of the logic


Deployment is a matter of subjective opinion - I personally much prefer to
use an MSI file to deploy new versions, and it works a charm for me in
terms of upgrading over old versions and also determining what versions of
the framework need to be installed. I've shipped CD's with the framework
on them and rolled it silently into the install, and I've sold apps online
with the MSI file rigged to download & install the framework if the user
needs it (and wants it). VB6 hasn't been updated in close to 10 years
now, and in terms of setup/deployment it's really showing its age. No
Windows Installer support, clunky COM DLLs, and the P&D Wizard looks
comically ancient now. It just isn't equipped to hang with the big boys
any longer.


Huh ?? well i can send you a link with a web bootstrapper ( installer 2.0 )
wich installs one of my products through the web
with an MSI


.Net is great for web development and for inhouse ( production system )
development where the above is no point
i love VB.Net and use it every day in my job as a inhouse software
developer , but if i wrote a commercial product that should be shipped on
CD / DVD i would still grab VB6 as my prefered tool.

That's great for you if that's what works for you - but that's still a
subjective experience. I've long since reached the point where I feel far
more comfortable with deploying a .NET app, not to mention making use of
the various features of keeping it updated in the future. To me, that's
one of (if not THE) most important aspects of shipping a desktop app to
multiple users, because when there are bug-fixes and new versions to be
deployed it's a piece of cake for me. I'd hate to think how I'd even
approach a problem like that if I had to go back to VB6.


No not for the runtime bit but to protect my coding against the concurency
send me a link to your product and i will proove my point by reverse
engineering it

I will send you a VB6 app and you can try to do the same that is my point ,



VB6 also gives you the largest user base .

Curious - what makes you say that? Do you have some stats you can base
this claim on, as presumably you're implying that more machines currently
in service today have the VB6 runtime installed compared to any version of
.NET?


Well actually having worked for the global market leader of automotive
catalogue software we actually did investigate this ( results are now
outdated as i left the company three years ago ) but it turned out that our
user base worked with old computers in there shops of at least +3 years old

A VB6 program can runn on every computer nowadays in service wether it has
the VB6 runtime installed or not ( the bootstrap takes care of that ) and if
you want there are tools that can merge the bootstrap in the executable so
that a installation isn`t necesary at all ( never used them but they do
exist )


Don't ge me wrong, I loved VB6 and coded a lot of great apps in it, but as
soon as something better came along I was hooked. If I had to go back to
writing apps in a non OOP language like VB6 I honestly don't think I could
now, unless it was something extremely simple. There's just been too many
steep advances in the language itself, let alone all the technologies that
the framework puts on the table, and that's before I've even started to
get my teeth into WPF, which is quite simply in a different universe to
VB6.


VB6 was as OOP as the coder who used it for a fact i wrote OOP style in
VB6 too, maybe that was the reasson why i adopted VB.Net so quick
if you own a copy of the Balena book a world would open for you i guess :-)
..

Trying to compare VB6 to VB.NET is like comparing a Trabant to a Mercedes
S Class. Sure the Merc is heavier, but I know which one I'd rather drive
around in every day.

-Alex

Well i use this analogy on my website "Visual Basic classic relates to
Visual Basic .Net as how a T-Ford relates to a Lamborgini murcielago"

I hope you understand my initial intention right , i agree with most of what
you say but with a slight twist and that is that VB6 wasn`t and isn`t so
bad at all
it is just another kind of beast and it should and could still serve some
needs that .Net simply can`t offer

MS could kill my biggest problem by shipping the lates framework in there
required servicepacks


Regards

Michel Posseth
http://www.vbdotnetcoder.com









.

Relevant Pages

  • Re: VB Application Wont Run on Other Machine
    ... You say the VB.net app was a conversion from a previously existing VB6 ... any dependencies. ... When I build an install package from VB6, ...
    (microsoft.public.dotnet.languages.vb)
  • Re: VB6 does not work in Windows Vista Business
    ... I had similar issues when I first installed VB6. ... After you install it you then need to enable the ActiveX installer service and restart the machine. ... it popup with an error "Error accessing system registry" and from ... 'ComDlg32.OCX' or one of its dependencies not correctly registered: ...
    (microsoft.public.vb.controls)
  • Re: VB6 does not work in Windows Vista Business
    ... VB6 seems to run fine now, but still it randomly comes up with "Error ... accessing system registry" which is rather weird. ... Install it from add windows components. ... 'mscomm32.ocx' or one of its dependencies not correctly registered:...." ...
    (microsoft.public.vb.controls)
  • Re: Forcing a VB6 application to run with administrative privileges
    ... I find manifest files work fine for my VB6 apps. ... Has anyone figured out how to have a VB6 application forced to run with administrative privileges yet? ... Microsoft talks about adding a manifest, a small piece of code, but that is for .Net based applications built with Visual Studio.Net and involves adding code to the web.config file and the resource table. ... As part of my install there is an AutoInstall program that takes up to six arguments. ...
    (microsoft.public.vb.general.discussion)
  • Re: Possible to distribute without dotnet framework?
    ... Sorry to disturb this happy party of bashing VB6 although i am a VB.Net ... to explictly select this bloated install wich nobody does if he isn`t aware ... The "special runtime" of .Net is called the .Net framework ... All the app has is some standard UI controls, buttons, etc. and a call to ...
    (microsoft.public.dotnet.languages.vb)