Re: .Net packaging/wrapper application?


"cj" <cj@xxxxxxxxxxxxx> wrote in message
news:ej7dp4LSIHA.5400@xxxxxxxxxxxxxxxxxxxxxxx
Can we bring back structured programming while we're at it? :) Oh nice
linear code--I just got this really peaceful feeling come over me thinking
of that.

Ooops, didn't last. You know maybe I'm not doing it right but with .net
have you run into the situation where you write code and put it on a
network drive and suddenly it doesn't work. You don't have permission to
run it or something. So for every pc that needs to run one of my programs
on the network I have to make sure it's got the correct version of .net on
it and then follow two different procedures, a gui one (MS .Net Framwork
1.1 Wizards) for 2003 and a command line one (caspol -m -cg 1.2 FullTrust)
for 2005 to set local intranet to full trust so we can use the program.
BTW what's up with going to a command line one for 2005? Are we moving
away from gui to the command prompt? And w/o these groups who would have
found that?

I have run into the same frustrations.

It seems to me that Microsoft is attempting the impossible - saving users
from themselves.

No amount of code or UAC propmts will save stupid users from installing or
running any free app that they see on the internet. All it will do is
frustrate everyone involved and make PCs more of a chore to use and less of
a pleasure.

That's why (IMHO) the fascination with PCs has fallen away. People that
used to love PCs now dread the very thought of changing their system or
loading a new software package at work. Why? Because they know it won't
work as advertised. They know they are in for at least a week of hell to
get back to a productive system - and that's a best case scenario.


I'm trying to get VS2008 now and I'm sure Vista is in my future. I
shudder to think what I'll have to do with them. I think we're coming to
a sad realization--allow or deny? :)

As of we'll have that choice in a couple more releases of Windows. Perhaps
they should consider renaming the OS Shutters?

Anyway, the only constant in this line of work is change so I'm moving on
now. Good luck in your quest.

Thanks! And to you too!

jim



jim wrote:
It was the same thing with COM and shared DLLs.

Microsoft thought that (due in part to the expense of hard drive space at
the time) that sharing DLLs would be an answer to the hard drive space
issue and would save RAM by allowinf several applications to share the
same DLLs.

It wasn't a bad theory, it just didn't work well in reality due to DLL
versioning issues. As a matter of fact, the simple answer to DLL Hell
for Visual Basic (and I suspect C++) apps was simply to place a copy of
the needed DLLs in the same directory as your executable. The way
Windows works is to look in the executable's directory for a needed DLL
BEFORE using the registry to find one EVEN IF THE REFERENCED DLL IS
REGISTERED ON THE PC RUNNING THE APPLICATION THAT NEED IT.

You didn't have to change one line of code or alter the method of
registering your DLLS. Just drop them in the EXE directory and, BAM, no
more DLL Hell. But, that was way too simple a solution - so we got .Net.

.Net has now gone back to keeping it's files in the same directory AND
using the registry to share .Net framework files.

So, now we are wasting drive space (not that it's that expensive anymore)
AND having to contend with a bloated 25MB+ framework and possible
application failures due to some developers using hotfixes to patch .Net
while others code around the issues found.

Eventually we will get back to the days of a single, linked and compiled
EXE - and it will be all new and shiny again.

!!!! WARNING! The following paragraphs may be offensive to Microsoft
Groupies! Read at your own risk! I will niether be responsible for your
overreactions nor will I respond to them. This is simply an observation
and remarking on another author's observatiuons. !!!!

That reminds me of an article I read the other day about how MS changed
the way apps used to work when they developed Windows. In the old Xerox
and Apple OS's that Gates observed before and while developing Windows,
there used to be something called time sharing (I think thats what it was
called) where all applications were placed in their own workspace and
could not access each other's memory or workspace. It kept applications
from screwing each other up.

Then, according to the author, Microsoft did away with this time
sharing/application segregation because they wanted the applications to
look and be more integrated with Windows in order to sell more software
(like Word, Works, Office, etc.). The author claims that all of this was
done to increase the market share of Windows apps and to increase revenue
for the investors (which, again, is what a corporation is good for).

Now, with the .Net framework, it seems we are getting back to the 1970's
idea of time sharing and application isolation.

I find it quite funny myself. Next, we'll be back to linked compiled
executables and praising it as another Microsoft breakthrough.

jim


"cj" <cj@xxxxxxxxxxxxx> wrote in message
news:uuk9TbJSIHA.1208@xxxxxxxxxxxxxxxxxxxxxxx
IMHO, I agree.

From my background in the late 80s dBase code needed a runtime and other
supporting files etc to be on the machine to make dBase programs work.
Along came Clipper which compiled essentially dbase code into one EXE
and that one file could be put on any dos or windows computer and run
from the command prompt or an icon etc. No installation or other files
etc necessary. This was touted the new, much faster and better way to
do things. I also worked with C and C++ back then and they also
compiled to one EXE file.

Years later along comes .net and it's new and better to go back to
needing something (.net framework) installed on a pc in order for you
apps to run. I have to shake my head--but whatever. Perhaps I'm getting
old and but what really bothers me is nobody seems to notice this--maybe
the 80s was before they got into programming. Everyone seems so
enamored by .net these days. I find it funny to think that in another
20 years, maybe less, .net will surely be just another memory, whatever
is out then will be oh so cool and nobody will understand why anyone
liked .net.

I don't mean to offend anyone with my comments, I surely appreciate the
help I get here. I just wish more folks seemed to understand where I'm
coming from. I might be happier with .net if I was allowed to jump to
an exclusively .net world and get all into it, but I sit here tasked
with writing web services in .net that sadly is to use a complicated
assortment of Visual FoxPro tables as data sources.


Jeff Gaines wrote:
On 27/12/2007 in message
<3d9fba1a222b18ca16f883192660@xxxxxxxxxxxxxxxxxxxx> Michael Nemtsev
[MVP] wrote:

Hello jim,

ok, what's from that list cant be done with Windows Installer? :)
except the point 3 the Windows Installed can do the same things, maybe
not so silently
Looks to me like Jim is looking for the .NET equivalent of compiling
with static libraries to produce a single executable. I'll add my vote
to his wish list :-)



.

Relevant Pages

  • Re: .Net packaging/wrapper application?
    ... the simple answer to DLL Hell for Visual Basic apps was simply to place a copy of the needed DLLs in the same directory as your executable. ... The way Windows works is to look in the executable's directory for a needed DLL BEFORE using the registry to find one EVEN IF THE REFERENCED DLL IS REGISTERED ON THE PC RUNNING THE APPLICATION THAT NEED IT. ... Perhaps I'm getting old and but what really bothers me is nobody seems to notice this--maybe the 80s was before they got into programming. ... Looks to me like Jim is looking for the .NET equivalent of compiling with static libraries to produce a single executable. ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Honestly Curious
    ... you can find other Windows apps that act in a similar fashion. ... Never heard of "dll Hell"? ... But then neither is using an uninstaller. ...
    (comp.sys.mac.advocacy)
  • Re: Using Windows Remove programs utilty
    ... I haven't used Setup Wiz or PDW in years (I use another setup package), ... setup packages of all apps that install and rely on the DLL). ... What does happen when user decides to remove that app from Windows using ...
    (microsoft.public.vb.general.discussion)
  • Re: Compiling on 64bit system
    ... Which will allow your .NET programs to run as 64-bit apps or 32-bit ... > Can somebody tell me if compiling on a system with Windows XP 64, ... system with 32bit versions of Windows and Visual Studio? ...
    (microsoft.public.dotnet.languages.vb)
  • Re: Green Hills CEO: Linux threat to free world!
    ... >>Well, I don't recall ever installing an application onto Windows, finding ... >>required an updated DLL, and when that DLL is installed finding that ... > Then you haven't used Windows. ... That's because Microsoft apps just install the DLL ...
    (comp.arch.embedded)