Re: From VC6 to .NET 2 questions

See below...
On Wed, 7 Dec 2005 15:01:06 -0800, "David Ching" <dc@xxxxxxxxxxxxxxxxxxxxxx> wrote:

>"Joseph M. Newcomer" <newcomer@xxxxxxxxxxxx> wrote in message
>news:kimep1hietttv1c7i0c3h7b2lc65605o72@xxxxxxxxxx
>
>> Note that there is no guarantee that an app which is installed via "copy"
>> will actually
>> run; historically, this has frequently been possible, but it is just good
>> luck. I don't
>> like predicating product success on dumb luck. Tech support is expensive.
>>
>> I'm not sure how a "great developer" reduces the dependency on fundamental
>> libraries; for
>> example, the OLE libraries, which historically have had a lot of bugs
>> which were fixed in
>> the redistributable libraries that come with the compiler.
>>
>> The assumption isn't mine; it's part of the specification of what a
>> distribution means.
>> Sure, lots of people get away with blatant violations of the installation
>> guidelines. It
>> doesn't mean that their approach is valid.
>
>I avoid OLE like the plague.
***
I do, too, but often I am inheriting a project with already-existing third-party ActiveX
controls, or something that involves automation, either as a client or server. I don't
actually use it myself, because I just don't have the time to become an expert in it...
****
>
>
>> Yep. That's a problem. But XCOPY doesn't fix it. For example, one way
>> to minimize
>> download was to use dynamic linking and assume that MFC42.DLL was
>> installed. Works fine
>> until you get into the situation of six or eight or however many
>> incompatible versions of
>> MFC42.DLL existed. I know. We hit them, when customers had used "copy"
>> to move (they
>> said "move", not "illegally duplicate") our product from one machine to
>> another. OTOH, we
>> could not use static linking because of a large number of MFC Extension
>> DLLs. Note that
>> assemblies, which deal with "side-by-side" installations which makes sure
>> that compatible
>> versions of DLLs exist but don't have to overwrite Windows\System32
>> versions (and hence
>> require reboots) require in most cases that the DLLs be included in the
>> distribution.
>>
>> Most of my clients are small businesses with very small (one programmer,
>> part-time) tech
>> support departments. They have to minimize tech support issues, and using
>> installers has
>> been a big part of what helps them. The *only* "instllation"-related
>> problems we have had
>> reported was when customers copied our application to other machines,
>> particularly older
>> Win9x laptops, instead of reinstalling it from the distribution image
>> (either downloaded
>> or CD). In many cases, it was just MFC42; in some cases, other, related
>> redistributable
>> DLLs are required (particularly when we use third-party ActiveX controls,
>> or components
>> such as MDAC; in some cases we don't distribute the Microsoft install
>> packages but simply
>> detect the wrong version is installed and request that they upgrade from
>> the Microsoft
>> site, but those decisions are not mine but my clients').
>
>I statically link to the CRT and to MFC, which makes XCOPY deployment
>possible. I don't know what problems with static linking you're talking
>about, you claim MS doesn't recommend it, but I've been doing this for
>years, and the fact is it works, on distributions of hundreds of thousands
>of installs. I use MFC controls and compile them right into the .exe. I
>don't use ActiveX controls, or the heavy database engines that MS provides.
>Why? Because it increases deployment reliability.
****
You get into trouble if you use MFC extension DLLs, because you end up with multiple
copies of the MFC runtime. Most of my clients have large suites of DLLs for a variety of
reasons. If you have a single executable, you can get away with static linking on good
days, but I haven't seen a project that simple in many years. And my clients have chosen
to use third-party controls (some of which are incredibly good), or database engines, for
various business reasons outside my control. I've only had one client who needed MDAC
installed at the correct version, and I was working in parts of the code not related to
the database interface, so all I had to do was write some code for them to make sure the
correct version was installed because it was part of their install support problem.
****
>
>Now if I need something like embedding the IE WebBrowser control or the WMP
>control, then I have no choice but to use ActiveX controls. But it is a
>design tradeoff at that point. Most people don't think twice about using
>these high risk components and end up with apps that require all manner of
>these things, then they wonder why they have so many problems.
****
I don't use ActiveX controls by choice, but the choice is rarely mine.

My clients use a lot of components, and because they use installers, they seem to never
have install problems. As I said, the only times we get support calls are when people
have attempted to copy instead of install. Since I'm often the support staff for these
companies, the support calls (other than how to use the program) come to me, particularly
during beta releases, so I really am on the front line of support for some of them. And I
get 3-5 calls a year (and yes, alas, some are for real bugs...) per product. And I know
that most of the support calls turn into "please install from the distribution CD" and the
problems go away.
****
>
>-- David
>
>
>
Joseph M. Newcomer [MVP]
email: newcomer@xxxxxxxxxxxx
Web: http://www.flounder.com
MVP Tips: http://www.flounder.com/mvp_tips.htm
.

Relevant Pages

  • Re: Authentication on PIX, WatchGuard, Safe@Office & SonicWall
    ... The mobile user software works well, I've not had any problems with it. ... I use it for clients that have traveling support or sales staff. ... in cases where I install something that the client might have ...
    (comp.security.firewalls)
  • Re: Another Best Practice Questioen
    ... No doubt the reason they don't install is that SMS 2003 RTM does not support ... Workgroup support is for Advanced Clients only. ...
    (microsoft.public.sms.setup)
  • Re: Using Terminal Services for client support.
    ... Our main reason for looking into switching programs is the clients we ... Many want us to use Terminal Services to support the servers we ... install rather than having to purchase a PcAnywhere license. ...
    (microsoft.public.windows.terminal_services)
  • Re: No MS Licence Support 24 / 7??? Client Add On Pack Password Problem
    ... When you purchase your replacement ... >> install and the Client Add on Pack disk will not allow me ... >> to install the clients on this different hardware without ... >> a password from MS support. ...
    (microsoft.public.backoffice.smallbiz2000)
  • Re: Access Treeview - Is it Safe Yet?
    ... This adds to the complexity of the install, ... I've already used it at 3 clients and the process is painless. ... I too, used to be a "I only like native controls" developer, but I've changed ... why did I review AccessUI? ...
    (comp.databases.ms-access)