Posted By: vesuvius | Aug 13th, 2008 @ 2:24 AM
page 1 of 1
Comments: 24 | Views: 1197
vesuvius
vesuvius
Das Glasperlenspiel
Miffed@

As .NET inflates, deployment of client applications has become an issue. The .NET client profile has come to the rescue, so a user only has to install this 28MB client profile, instead of .NET 2.0, 3.0, 3.5 and all the service packs. This reduces the install size from 500MB+ (on XP) to just 28 MB. The install size on an XP machine is about 53 MB. Sweet!

The only problem is if you want to create an install CD for your Winforms or WPF application you cannot. It is designed to be installed over the internet. Should you want to install it locally, you have to go through the tedium of creating a webserver etc. A lot of people are going to be annoyed at this because it introduces a dependency on the internet, for their application to run. Quite why things must be this way, is all but a mystery to me?
jh71283
jh71283
Throw new System.Beverage. OutOfCoffeeException​()
Oh FFS you must be joking. And if you're not joking I hope you're wrong.

That is the stupidest thing I have heard in a while, (even worse than when the sync framework neglected mobile devices).

Almost all of my target machines will have no connection to the internet, and everyone complains how long our software takes to install (They don't realise that the 40+ minutes is taken up with all the microsoft crap, and then about 30 seconds for my app to deploy)

I was hoping the client profile stuff would solve this one....


 Gues that's my fault for thinking that they would have thought it through.
But the whole point of having a client profile version in the first place was to avoid users having to do large downloads to install a single application. If you're installing off a CD then you can easily include the full framework installer. What's the problem again?
jh71283
jh71283
Throw new System.Beverage. OutOfCoffeeException​()
Even better - the client profile is all but useless on Vista. Vista will still need the full install, due to it already having .Net 3.5.


In short, if you have any version of the .Net Framework 2.0 onwards installed, the client profile will not install, and you will require the full framework.


So, instead of cutting down the size of our setup deploymants, this potentially increases them, because (if we find a way) we will not only have to include the 28Mb client profile, but we will also need to carry the full .Net 2.0, 3.0 and 3.5 runtimes, just in case the target machine happens to already have the framework (which, thanks to windows update, it pretty likely)


So exactly where is this client profile going to be useful?

Deployment Guide said:
As is illustrated in the preceding table, the Client Profile deployment is focused on Windows XP SP2+ with No Framework components installed


Well that scenario is getting rarer and rarer, thanks to there being no way of buying XP SP2 any more, and windows update is pushing .net 2.0 onto the machines anyway, so you have a very tiny opening in which the client profile is of any use - that being directly after XP SP2 has been installed, and before the windows updates are applied.


Oh well...
jh71283
jh71283
Throw new System.Beverage. OutOfCoffeeException​()
AndyC said:
What's the problem again?


Installation time.

Net 3.0 upwards just take a silly amount of time to install, which gives the end user a negative impression of our software out of the box..


it's not the best start.
vesuvius said:
The client profile only has the client .dlls and omits ASP.NET, WCF, WWF for example so is a sweet 28MB download (and it installs once). The full  install size is 53 MB - a tenth (at least) of what it was previous. If you ask an IT department to deploy your application and they have to install 3 seperate frameworks, and then your app, they will tell you to hop it. Think of deploying this on 500 machines as an IT head.


Um, that's my day job. It's really not an issue. In fact it's pretty trivial. I think this is one of those areas that developers get all bothered about for no reason.

Where it is in issue is:

If it's a signifcant change in infrastructure, there is considerable testing time needed. So organisations with .NET < 3.5 apps are going to be somewhat hesitant about installing updated frameworks and the potential for breakages.

Joe Bloggs downloading over the internet. In which case they can now use the client profile, reducing the overall download time. 
jh71283
jh71283
Throw new System.Beverage. OutOfCoffeeException​()
Andy, I'm not trying to blow smoke up your ass, but I imagine you are one of the better IT heads out there, and you will use AD to deploy and other such technologies.

There are a lot of "IT Heads" who think that a ram upgrade is a complicated job, and they are the ones that would baulk at the idea of these installs.
Pace
Pace
In The Mix...
The prequesites not help with your deployment if you are experiencing long wait times? AFAIK you can include the framework as an option to install from the same location as your app at install time no?
jh71283
jh71283
Throw new System.Beverage. OutOfCoffeeException​()
Yes, but it is not the download time that is the issue, it's the install time.
jh71283
jh71283
Throw new System.Beverage. OutOfCoffeeException​()
Vesuvius said:
There is no two ways about it. An offine install of the client profile should have been made available.


And, IMO, the client profile should be flexible, so that you can have installs such as


.Net 3.5 SP1 Client
=================
.Net 3.0 SP2 Client
=================
.Net 2.0 SP2 Full Install



As it stands, at has to be all Client or all Full Install.

Pace
Pace
In The Mix...
Ah I see! Sorry guys, my bad
What. Like this one?

Although I'd be mighty impressed if you can find a machine that takes 2 hours to install even the full runtime and is capable of running WPF apps.
jh71283
jh71283
Throw new System.Beverage. OutOfCoffeeException​()
WPF apps run perfectly on 600Mhz macines, running WEPOS.

.Net framework 3.5 takes a long time to install on these.

I still don't see where you're getting this 500MB install from, even the full version of .NET 3.5 is only 197MB and, given that 2.0 and 3.0 are both installed on Vista, it's pretty swift to install there. Obviously it's going to take longer on XP with no framework but if your only doing WinForms apps you do have the option of targetting an earlier version, to reduce the amount that needs installing.

Obviously it's going to be bigger than the web install, because the web install is downloading only selected parts of it. That's kind of the point of the web based installer. But I thought you said it wasn't size that mattered, only installation time. Extracting the 50-odd meg that actually gets installed from a local cache is surely faster than downloading it and installing it?

I read the link and am not sure what you mean about drilling down into the registry. There are a couple of keys that can be used to detect if it's already installed. Should be trivial to knock up some installation conditions based on them in Windows Installer (and presumably any other installer engine for that matter).

vesuvius said:
The .NET 2.0 redistributable, install will be 120 - 150 MB (may be more with framework specific service packs)
The .NET 3.0 redistributable, install will be 120 - 150 MB (may be more with framework specific service packs)
The .NET 3.5 redistributable was 50 MB last time I checked (will be more with the new .NET 3.5 SP1 as that is a huge service pack)


Ah, now I see the problem.

You don't need the .NET 2.0 or 3.0 redistributables at all. The 3.5 full file one (197MB) installs all of them. There presuambly is, or will soon be, a 3.5 SP1 version that integrates the whole lot into one package.

If you doing all three individually, no wonder it's taking ages and seems massive.
PerfectPhase
PerfectPhase
"This is not war, this is pest control!" - Dalek to Cyberman

The fully loaded 3.5-SP1 is 231.50MB for combined x86/x64/ia64
The Add/Remove figures is based on very, very, very bad heuristics*. If you go look in C:\Windows\Microsoft.NET you'll see there is nothing like that much installed. Installing the full 3.5 framework here on even an old 1GHz machine from a CD is a few minutes max.


*If the figure on mine was even nearly true .NET 1.1 alone would be over 1GB.
I'll give you that the Add/Remove figures are wildly off base (why the heck doesn't Microsoft do something about this, at the very least for their own installations?).  However, you're also wildly off base if you're only looking in C:\Windows\Microsoft.NET.  Stuff gets installed in more places than that.  At a minimum, there's also C:\Program Files\Microsoft.Net and C:\Program Files\Reference Assemblies.

I don't think the size of the installation means anything though.  What's important is the installation experience.  How long it takes to install and whether or not a reboot is required are all that really matter (at least when talking about installation through media and not over the network, where size can be more important and not only because it effects the install time).  I'm not claiming that there's an issue here, but if vesuvius still thinks that's a problem (once he stops running multiple installers), then you have no room to argue with him.
wkempf said:
Stuff gets installed in more places than that.  At a minimum, there's also C:\Program Files\Microsoft.Net and C:\Program Files\Reference Assemblies


To be honest, I thought that was pretty much just NGen'd stuff that was done post-install, but I'm quite willing to be entirely wrong on that score (though it's still a long way off 500MB).

wkempf said:
I'm not claiming that there's an issue here, but if vesuvius still thinks that's a problem (once he stops running multiple installers), then you have no room to argue with him.


Sure. If you have a metric of "It must take less than X on a machine of spec Y" and you're doing the minimum possible and not reaching that target, then you have an issue. What had me somewhat confused was how wildly different the figures (both in terms of size and time) to what I was actually expecting to see, suggesting that something somewhere wasn't adding up.
page 1 of 1
Comments: 24 | Views: 1197
Microsoft Communities