Re: .Net packaging/wrapper application?

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'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? :)

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


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?
    ... it just didn't work well in reality due to DLL ... Windows works is to look in the executable's directory for a needed DLL ... the way apps used to work when they developed Windows. ... Looks to me like Jim is looking for the .NET equivalent of compiling ...
    (microsoft.public.dotnet.framework.aspnet)
  • addsourcefilter locking file in windows
    ... I'm new to this group and somewhat new to directshow programming. ... with windows programming. ... I wrote a C++ MFC dll that I am calling from a VB6 application. ... and builds a graph. ...
    (microsoft.public.win32.programmer.directx.video)
  • Re: Redirecting stderr
    ... programming newsgroup. ... There's no DLL support in the Unix version I use, ... If the code uses DLLs on Windows and shared libraries ...
    (comp.lang.c)
  • Re: Base Classes in .exe, derived classes in .dll
    ... >> on Windows you cannot export symbols from an executable. ... E.g. how can I link an DLL importing some symbols by specifying an EXE ... Maybe via email to avoid offending some people here (which do programming ... without an underlying OS)... ...
    (comp.lang.cpp)
  • Re: [SLE] Developing a Real Time Data System
    ... The KBasic License is valid for both operating systems: Windows and Linux. ... Modern BASIC language ... chapters learning about the programming language. ...
    (SuSE)