I thought he was trying to say mass-a-chew-sets, in a nonchalant but emphatic manner. You're better placed to decide though!wisemx said:They used to spell it like this: Massachusetts
People just need to be realistic and realise that they will get an anaemic version of WPF, and most of the decisions are based around keeping the Silverlight runtime as minute as possible. Why for example have they elected to use the winforms or should that be base class library background worker component, instead of the WPF dispatcher for multi-threading? That begs the question why they even bothered creating the dispatcher library in the first place?Bas said:I'm kind of perplexed about this too. I realise that what with Silverlight being a subset of the WPF features, things change, stuff like the difference between Labels and TextBlocks baffle me. I had hoped that by just copying the XAML you could easily recreate a WPF interface in Silverlight most of the time, but apparently not.
Maybe we can get a going deep video about the various reasons for this? Maybe to commemorate Silverlight 2.0's release, which surely must be any day now?
Most WPF gurus are very vocal about the lack of triggers - they are a trigger happy bunch. What I think the solution is, is to have a two tier Silverlight application. If the .NET client profile is installed on the machine, then it will run the Silverligh application is the most rich representation possible for the appplication. If not, a trimmed down version is run.
The emerging difference between WPF and WPF/E is down to libraries available - or should that be unavailable.
I'm just trying to figure out what the sync framework is?littleguru said:vesuvius said:*snip*
I recently watched this Visual Basic Vid about synchronising SQL Server and SQL compact. Is this a part of it and are you involved in some way with it? As a C# MVP (or former), I'm under the impression that this, like the dataset designer etc. is owned by the Visual Basic team (which is why most C#'ers dislike them - datasets that is)
Blowdart "carries on" about resharper as well (if I remember correctly) so it may need to be looked into.Yggdrasil said:One of the greatest features of Resharper is its ability to mark unused code and usings on the fly (greyed out), as well as rearranging using statements intelligently (seperating by root namespace, for instance).
Foolishly speaking, I think Visual Studio should leave a bit of a mess behind. When learning to use the IDE, and you application is slow, you learn to know all the libraries that you application is referencing. If you are a novice and start with a sparse reference set, Visual Studio isn't too much help in letting you know which library to reference. In fact that is probably VS's weakest point, i.e. libraries, and it is a hard problem to fix.
I'm sure the seasoned developers (espescially those from a #include <iostream.h> background) will tell you that you're being plain lazy.
Spec# will get rid of most of these
Well I have leanet something there - that I knew already. No wonder you were so nonchalant. I wrote an XML splitter for a chap somewhere because they were limited to transferring 5MB XML files of orders using the electronic data transfer system (I cannot remember what it was called), and after writing the application, I learnt to always right click the application for the correct number of bytes. I passed this information onto him, and he soon found he had a far smaller problem than he initially thought.AndyC said:vesuvius said:*snip*
*If the figure on mine was even nearly true .NET 1.1 alone would be over 1GB.
Anyway the .NET client profile size is approx 53 MB
.NET 3.5 on XP is 110MB
and the full .NET 3.5 on SP1 is 159MB
I seem to remember having heater discussions on .NET and the fact that it is bloated, but 160MB of code covering web, client, WCF, WPF etc. does not seem like a lot
I happen to have copies of a test XP virtual machine that just has XPSP3.AndyC said:vesuvius said:*snip*
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.
I downloaded the .NET 3.5 bootstrapper
Guess what it installed?
That's 455MB of framework code, not including the new SP1. I cannot compare speed with my PC but a CD that installs 55MB of client profile is by far and away better than one that installs 500+MB of framework code.
In all fariness this is in the pipelinejh71283 said:Pace said:*snip*
it's just typical poor timing between the MS dev teams. (see also my rant about there being no SQL management studio express for 2008)
This is all available at http://www.microsoft.com/express/sql/download/
So far I am pleased that express was available on August 12, they had said at the end of the month. whne SQL 2005 express was released, there was a similar delay. It may well be woth subscribing to the RSS feed at http://blogs.msdn.com/sqlexpress/
I cannot believe that it is this difficult to get through to an IT professional the problem. Why do you think they created the client profile anyway? Nevertheless I will try.AndyC said:vesuvius said:*snip*
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).
The company I am writing software for at the moment have upgraded their old machines to dual cores, but on most have retained or re-installed XP. That is the year 2008.
I have a test application I intend to distribute on CD. At present the requirements are
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)
Windows Installer 4.5 Redistributable 50 MB (will have SQL 2008 express - the test application)
Size does matter because with SQL express and my application you looking at 400MB, plus my application files and SQL server. Plus when you take into account that the install time for each framework is ages, your obtuseness and failure to grasp this simple dilemma leaves me rather perplexed?
Were the client framework available as an off-line install I would have;
Client profile - 28 MB resulting in a 5 min install
My application files etc, giving the users only what they need.
Maybe its because I am fastidious about the way I write code. I try to never have anything superfluous. If you don't need System.XML.Linq then remove the reference to it. This is one of the easiest and quickest ways to improve application performance.
If you then take into account .NET cold start up times, and the .dlls needed to be loaded into memory, its a best practice to only have the libraries you need. If you cannot see the problem with installing all these frameworks, just for the sake of it, I have run out of steam in this thread.