Solved Netframe Work 4.0/2.0

[Layback Bear]

I have Netframework 4.0 do I need to keep the older versions? Can I just remove all the older ones I find on my computer?

 

[Mike Connor]

I have Netframework 4.0 do I need to keep the older versions? Can I just remove all the older ones I find on my computer?

Yes, you can remove them. I would advise you to download this;

Download details: Microsoft .NET Framework 4 (Standalone Installer)

and install it.

Then run an update.

Regards....Mike Connor

 

[johnnya]

Good morning Layback, good to see you. From what I have read, each "version" of Netframe is actually a separate program, not an update. It is possible that if you delete an earlier one, that a program on your system written to specifically use that one will no longer work. They can happily co-exist with each other.
Hope this helps
Regards
JohnnyA
EDIT: Oops Mike beat me to it. I will defer to Mike's greater experience. Sorry.

 

[Mike Connor]

Good morning Layback, good to see you. From what I have read, each "version" of Netframe is actually a separate program, not an update. It is possible that if you delete an earlier one, that a program on your system written to specifically use that one will no longer work. They can happily co-exist with each other.
Hope this helps
Regards
JohnnyA
EDIT: Oops Mike beat me to it. I will defer to Mike's greater experience. Sorry.

That was the case, but the basic versions are now part of the standard Windows 7 install. ( Or updates). Some problems arise because the "Standard" client which is installed does not have the same functionality as the "Standalone" version. Some software wont run on it.

If the old versions are "Installed" ( i.e. visible in your installed programs list), then you can simply remove them.

In Windows features, the .net 4.0 is not shown even after you install it. This still shows .net 3.5.1 ( Which actually includes all the older versions).

The .net 4.0 does show up as an "Installed" program in the installed programs list.

Regards....Mike Connor

 

[johnnya]

Thanks Mike. Good to know for future reference.
Regards
John

 

[Layback Bear]

Good day to you both. I have just down loaded form the site you gave and installed. Shut down and re booted. Now in add/remove I have NFW 4.0 client profile and NFW 4.0 extended which I just installed.
Just to be sure so I don't monkey duck things up. Now can I remove NFW 4.0 client profile and all older NFW'S including from registry if they are there still?

 

[Mike Connor]

Good day to you both. I have just down loaded form the site you gave and installed. Shut down and re booted. Now in add/remove I have NFW 4.0 client profile and NFW 4.0 extended which I just installed.
Just to be sure so I don't monkey duck things up. Now can I remove NFW 4.0 client profile and all older NFW'S including from registry if they are there still?

I don't understand what you want to do? Normally there should be nothing else there. The Installer does most of what is necessary regarding what is installed, and the update does the rest, There is nothing to remove.

You must run a windows update after installing using the standalone installer, it adds a few things, and may well remove a few things as well.

Regards....Mike Connor

 

[Layback Bear]

AHHH The update. Sorry I was in a hurry to get to the Computer store and forgot the update. It cleaned everything except NFW 4 client profile out of the add and remove and registry.

 

[Mike Connor]

AHHH The update. Sorry I was in a hurry to get to the Computer store and forgot the update. It cleaned everything except NFW 4 client profile out of the add and remove and registry.

Excellent.

Don't rush to the computer store, doing that can cause all sorts of problems;


To the tune of "Arthur McBride";

I bought a computer, my joy and my pride,
till I opened the casing and looked down inside,
when I saw what was in there, I damn nearly cried,
but the casing is pleasant and charming............

So off to the chip shop in haste I did stride,
and I took my nice casing along for the ride,
the nice young man there said my hard disc had died,
but the casing was pleasant and charming..........

So I bought a new hard disc and a fist-full of RAM,
regardless of cost now, I don't give a damn,
a new CPU then I also did cram,
in my casing so pleasant and charming.............

It still did not run well, my reckoning tool,
and the man at the shop said you've been a right fool,
with all of that stuff in, it needs to stay cool,
in the casing so pleasant and charming.......

All of the new stuff was melted and fried,
and the casing still looked nice, but smelled bad inside,
I could not believe it, and very wide-eyed,
I stared at my casing so charming..................

So come all you fellows and mark well my tale,
it might well save you a rant and a rail,
Beware of fine casings, for affection will pale,
though the casing is pleasant and charming.........

Regards....Mike Connor

 

[Layback Bear]

Thanks Mike, once again you made things easy form me. It won't let me give a rep.
Windows 7 must of installed installed it where it belongs because, I'm still 0% fragmented.

 

[niemiro]

Hello all!

.net Framework is a confusing beast. Hopefully I can unmuddle everyone!

.net Framework 3.0 and 3.5 and not true new versions. They both build on version 2.0, and therefore require 2.0 to operate. If they had repackaged all of the unchanged files, wasting disk space of course, they would have been called proper versions. If a file in 3.0 is unchanged from 2.0, it just redirects to 2.0, storing only the changed files. This is very understandable.

• 1.0: Proper .net Framework.

• 1.1: Relies on 1.0 being installed. If it is not, it installs 1.0.

• 2.0: Proper .net Framework.

• 3.0: Relies on 2.0 being installed. If it is not, it installs 2.0.

• 3.5: Relies on 3.0 and 2.0 being installed, and installs them if necessary.

• 4.0: Proper .net Framework.

• 4.0 Extended: Relies on 4.0 Client version being installed, and installs if necessary (Full package includes Extended, Client package does not)

• Updates for any of them (such as security updates): Require the associated full version.

• Service Pack (SP1 etc.) Redistributables downloads from the Microsoft website: Obviously require the original version to actually work, but HAVE THEM BUILT IN! Downloading the original version prior to Service Packs from the Microsoft Download Centre is NEVER required. Don't fret! (not Windows or Office Service packs obviously; this only applies to .net Redist and Visual C++ Redist Service Packs) Security updates DO NOT have the original version built in.

.net Framework are separate applications which install side by side, and compliment and NEVER conflict. Well done johnnya! Very well done.

• Vista: Includes .net Framework 3.0 (and 2.0 to make it work) by default (Windows Features)

• 7: Includes .net Framework 3.5 (and 3.0 and 2.0 to make it work) by default (Windows Features)

So, they are designed to be installed side by side, but do you need them all?

Basically, yes. Certainly, uninstalling 2.0 and 3.0 will break 3.5. Trying to uninstall 4.0 Client will break Extended (although you won't be able to with the normal uninstaller anyway because that will really mess things up!)

So, do you need them all!?

An application coded for 4.0 will not work on 3.5. This is obvious. An application coded for 3.5 will not necessarily work on 4.0.

So YES! You need to keep them all!

In theory at least, to make every application run, you need all of the following .net Frameworks:

1.0 (1.0.3705)
1.1 (1.1.4322)
2.0 (2.0.50727)
3.0
3.5
4.0 (4.0.30319)

However, 1.0 and 1.1 are SO old that you NEVER, and I actually mean NEVER EVER EVER EVER need them on Vista and 7.

You most certainly need 2.0, as that is what most applications use. Then 3.5, and then 4.0 (number of programs using them) I am not quite sure where 1.0, 1.1 and 3.0 fit in.

So, leave them all installed would be my advice.

And just for completeness, a little bit about Client and Full:

The size difference is marginal. 41.0MB vs. 48.1 MB. The Full is required if you create .net Applications from scratch (ie you are a programmer) It contains a few additional features. Just a few. You as an end user won't use them. You only really need Client. If, however, you DO happen to install an application which uses these features, it will bundle the Full in as well. It will do, because it knows that almost no users will have the Full, and the application will crash if it doesn't bundle it in with the installer. You will then have the Full.

For the sake of a few MBs, and a quicker install some time later, just leave the Full on your system.

For further information about Client and Full, see:

• What
• .net 4.0 - Difference between .Net4 Client Profile and Full Framework download - Stack Overflow

So, leave .net Framework well alone, otherwise applications requiring it which do not bundle it with the installer (bad applications, they ALWAYS should) will crash - Stopped Working and was Closed most likely.

And after all, any non-defaultly installed .net Frameworks has either been installed by you, or far more likely, but one of your favourite applications which will now crash without much warning or explanation.

One final quote from cluberti, MCTS: Windows Internals, MCITP Server 2008 EA, MCTS MDT/BDD, MCSE/MCSA Server 2003

It's important to note that 3.0 and 3.5 are NOT technically full versions of a framework - for these to work correctly, you MUST have 2.0 installed. 3.0 and 3.5x provide additional functionality, but they do NOT work without the base 2.0 package (which is why you see the 3.5 redistributable on the web installing 2.0, 3.0, and 3.5 components!!!). The simple answer is, please don't do that. You'll break the entire framework. If you really need 3.5 installed on machines, get the 3.5 SP1 full network installation package, and use that installer to install 3.5 SP1 - it will update the 2.0, 3.0, and 3.5 .NET runtime components on the machine, although there are still security updates for those versions that you will need to also install manually or via windows update after installing 3.5 SP1 on XP. If you need 3.5 for Windows 7 or Server 2008 R2, simply enable the .NET feature in the "Turn Windows features on or off" control panel applet within the Programs section (or if you're a CLI guy, use dism.exe to add or remove the feature from a cmd prompt).

I hope that this helps, and clears up all confusion.

Richard

 

[Mike Connor]

Well, that all sounds very interesting, very complex, and it's not true.

Windows 7 installs the .net framework by default. Currently it installs 3.5.1 with backward compatibilty to 2.0. This is what you see in the "Features" window. This assumes that you have all updates and service packs.

If you download and install .net 4.0 using the standalone installer, then everything runs perfectly well, including all the old software, and applications coded for .net 4.0 also run perfectly, ( which they wont on the "standard" installation).

The .net 4.0 installation is shown under your "installed programs" list. The Windows features still shows 3.5.1

If you have any other packages "installed" they are superfluous. If you use the 4.0 standalone installer, and run an update afterwards, it adds some things and removes some things.

That is all there is to it.

This software for instance;

http://code.google.com/p/dngrep/

will not run on the standard installation. It simply returns various errors, Usually "dnGrep has stopped working".

Once you have installed and updated the .net 4.0 using the standalone installer, followed by an update, it works perfectly. There are a number of others.

Saying that these are "Bad" applications is rather silly. If it was necessary to bundle the full .net framework with every application that used it, or even any appreciable part of it, then there would be no point in having it at all. It is basically a function library, a framework, like Java, which saves programmers a lot of work.

Some of what you wrote applies to Windows XP, but it does not apply to Windows 7.

It is also not possible to remove the versions installed by default into Windows 7 without breaking Windows. They do not appear in "Installed Programs" and are not uninstallable as such, although you can disable them in Windows Features.

Regards....Mike Connor

 

[Layback Bear]

Well Mike I did it like you instructed and everything seams to work as it should. Thanks again.

 

[Mike Connor]

Well Mike I did it like you instructed and everything seams to work as it should. Thanks again.

My pleasure.

I have now done this lots of times, on a number of machines, and also looked quite closely into it because it confused the hell out of me as well!

The first few times I did it were "trial and error" because I could not get some software to work, but I quickly discovered that it solved a lot of other problems as well. I have no idea why there is no proper documentation on some of these things. Makes things a lot more difficult than they need to be.

I hate it when I have useless stuff on my machines, and I also hate it when various stuff doesn't work properly, and I tend to get somewhat anal about it!

Regards....Mike Connor

 

[Layback Bear]

I also hate useless stuff but I guess that's obvious. When I go to Microsoft site and read about things they get off in super geek world and I get lost at times. I'm in Geek training 101.

 

[niemiro]

Well, that all sounds very interesting, very complex, and it's not true.

Windows 7 installs the .net framework by default. Currently it installs 3.5.1 with backward compatibilty to 2.0. This is what you see in the "Features" window. This assumes that you have all updates and service packs.

If you download and install .net 4.0 using the standalone installer, then everything runs perfectly well, including all the old software, and applications coded for .net 4.0 also run perfectly, ( which they wont on the "standard" installation).

The .net 4.0 installation is shown under your "installed programs" list. The Windows features still shows 3.5.1

If you have any other packages "installed" they are superfluous. If you use the 4.0 standalone installer, and run an update afterwards, it adds some things and removes some things.

That is all there is to it.

This software for instance;

dngrep - dnGREP - Google Project Hosting

will not run on the standard installation. It simply returns various errors, Usually "dnGrep has stopped working".

Once you have installed and updated the .net 4.0 using the standalone installer, followed by an update, it works perfectly. There are a number of others.

Saying that these are "Bad" applications is rather silly. If it was necessary to bundle the full .net framework with every application that used it, or even any appreciable part of it, then there would be no point in having it at all. It is basically a function library, a framework, like Java, which saves programmers a lot of work.

Some of what you wrote applies to Windows XP, but it does not apply to Windows 7.

It is also not possible to remove the versions installed by default into Windows 7 without breaking Windows. They do not appear in "Installed Programs" and are not uninstallable as such, although you can disable them in Windows Features.

Regards....Mike Connor

Hello Mike!

I bow down to you, I may well be very wrong. However, may I just confirm a few things for my own knowledge?

The only bit you are disagreeing with is whether a .net 3.5 application will run on .net 4.0. Is that the only bit you are disagreeing with, or is some of the rest incorrect as well?

Thanks a lot!

Richard

 

[niemiro]

Hello again!

I take your point about whether bundling .net is necessary or not is open to debate. But let's take it that the program will crash if the correct version is not installed (however true or false that may be - that is for later in this post) and if the program crashes then most users will not know how good/bad the application is, sees that it is "buggy" and give up. I personally think that all installers should download the correct .net if, and only if, it is not already installed. No additional downloads from the Microsoft website (because the user would likely have had to download a new copy anyway - not many users will have the download lying around to hand, but not even have Client installed) Then the program cannot crash. This is obviously personal, but why allow your program to crash, at almost no extra download time (too few additional kilobytes to matter)? I think that applications which do not do this are indeed a little bit "Bad". IMO.

So, will a .net 3.5 application run on 4.0 (and I don't mean specifically those versions (1.1 and 2.0 for example))

I think that it will not necessarily. But I will take counter arguments properly. I have no issues about being shown to be wrong. We are all learning, and it is quite likely that I am wrong if you are so sure. My evidence:

The .NET Framework 4 is highly compatible with applications that are built with earlier .NET Framework versions, except for some changes that were made to improve security, standards compliance, correctness, reliability, and performance.

The .NET Framework 4 does not automatically use its version of the common language runtime to run applications that are built with earlier versions of the .NET Framework. To run older applications with .NET Framework 4, you must compile your application with the target .NET Framework version specified in the properties for your project in Visual Studio, or you can specify the supported runtime with the <supportedRuntime> Element in an application configuration file.

The source: What's New in the .NET Framework 4

The .NET Framework version 3.0 and 3.5 use version 2.0.50727 of the CLR.

The source: <supportedRuntime> Element

Thank you all, and thank you Foxfire, your method works. And there is one tricky thing that I would like to share is the order of nodes.

When I set it like this below, it works both for 3.5 and 4.0.

<startup>
<supportedRuntime version="v4.0" />
<supportedRuntime version="v2.0.50727"/>
</startup>

And if I change the order, the APP will crash on the OS has only 4.0 installed.

<startup>
<supportedRuntime version="v2.0.50727"/>
<supportedRuntime version="v4.0" />
</startup>

Net 3.5/2.0 Applications do not automatically run on the .Net 4.0 runtime. You have to specify explicitly for your application that it should run on .Net 4.0 in your App.config by adding:

<configuration>
<startup>
<supportedRuntime version="v4.0" />
</startup>
</configuration>

In case you have third party components you also have to mark them as being ready for 4.0:

<configuration>
...
<runtime>
...
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
...
<dependentAssembly>
<assemblyIdentity name="AssemblyName" publicKeyToken="31bf3856ad364e35"/>
<bindingRedirect oldVersion="3.5.0.0-3.5.0.0" newVersion="4.0.0.0"/>
</dependentAssembly>
...
</assemblyBinding>
...
</runtime>
...
</configuration>

The source: wpf - BackwardcCompatibility of .NET Framework 4 - Stack Overflow

Read this blog: Multi-Targeting Support (VS 2010 and .NET 4 Series) - ScottGu's Blog

I think that I am right! But I accept that I may well not be.

I hope that we can make a good debate out of this, because it is a very interesting topic.

Richard

 

[Mike Connor]

Hello again!

I take your point about whether bundling .net is necessary or not is open to debate. But let's take it that the program will crash if the correct version is not installed (however true or false that may be - that is for later in this post) and if the program crashes then most users will not know how good/bad the application is, sees that it is "buggy" and give up.

Yes, programs will crash if you try to run them on a .net version for which they have not been coded, or if certain things are missing. I have a number of programs which would not run at all on the "Standard" installation. I "killed" Windows a couple of times trying to troubleshoot this.

Since then, whenever I have had any problems at all that might impinge on .net, I have simply downloaded the standalone .net 4.0 installer, and this has cleared them.

The installation I have on this machine for instance;





(This is Windows 7 x64 ultimate).

The basic Windows default installation shows 3.5.1 but also contains the versions back to 2.0.

NO software coded for .net 4.0 will run on the standard installation, and none of it which I have used to date included the necessary files to run them. They only worked after downloading the full standalone installer. I have had the same problem on a lot of Windows 7 machines, and the problem is also similar. ( but not actually the same, more like you described, on XP ).

I personally think that all installers should download the correct .net if, and only if, it is not already installed.

That would doubtless be sensible, but such ideals are never achieved. Also, when some software does not run, many users have no idea what to do about it, and give up. The basic idea behind the integrated .net framework is that nobody should have to download anything, it is built in.

Also, that is basically impossible on Windows 7, because the default installation is part of the operating system. The only .net software you can now ( normally ), install directly is .net 4.0.

No additional downloads from the Microsoft website (because the user would likely have had to download a new copy anyway - not many users will have the download lying around to hand, but not even have Client installed) Then the program cannot crash. This is obviously personal, but why allow your program to crash, at almost no extra download time (too few additional kilobytes to matter)? I think that applications which do not do this are indeed a little bit "Bad". IMO.

Well, what users might or might not have is not relevant here. ALL Windows 7 users have a .net framework installation compatible with versions 2.0 to 3.5.1 That is the default.

So, will a .net 3.5 application run on 4.0 (and I don't mean specifically those versions (1.1 and 2.0 for example))

The question does not arise, it can not arise, because those versions are installed by default.

However, anything coded for 4.0 will not run on the standard installation.

I think that it will not necessarily. But I will take counter arguments properly. I have no issues about being shown to be wrong. We are all learning, and it is quite likely that I am wrong if you are so sure.

It's not a question of being right or wrong per se. It is a question of how and why this stuff works, and the various extremely complex explanations often given for it. They are all superfluous in regard to Windows 7, and merely serve to confuse people.

Older versions of software using .net framework are compatible by default, under normal circumstances you can neither install nor uninstall them, they are an integral part of the operating system on Windows 7.

You still have to install them on XP, and your previous comments are relevant in that case. There, you have to have the versions installed for which the software you want to use is coded.

Various theoretical musings may be interesting, but they don't help anybody in this situation. You can not influence the default installation in Windows 7, which is currently 3.5.1 ( although you can disable it in "features"),You can however install 4.0.

So discussions on the merits or necessity of previous versions are completely superfluous in regard to Windows 7.


My evidence:

The .NET Framework 4 is highly compatible with applications that are built with earlier .NET Framework versions, except for some changes that were made to improve security, standards compliance, correctness, reliability, and performance.

The .NET Framework 4 does not automatically use its version of the common language runtime to run applications that are built with earlier versions of the .NET Framework. To run older applications with .NET Framework 4, you must compile your application with the target .NET Framework version specified in the properties for your project in Visual Studio, or you can specify the supported runtime with the <supportedRuntime> Element in an application configuration file.

The source: What's New in the .NET Framework 4

The .NET Framework version 3.0 and 3.5 use version 2.0.50727 of the CLR.

The source: <supportedRuntime> Element

Thank you all, and thank you Foxfire, your method works. And there is one tricky thing that I would like to share is the order of nodes.

When I set it like this below, it works both for 3.5 and 4.0.

<startup>
<supportedRuntime version="v4.0" />
<supportedRuntime version="v2.0.50727"/>
</startup>

And if I change the order, the APP will crash on the OS has only 4.0 installed.

<startup>
<supportedRuntime version="v2.0.50727"/>
<supportedRuntime version="v4.0" />
</startup>

Net 3.5/2.0 Applications do not automatically run on the .Net 4.0 runtime. You have to specify explicitly for your application that it should run on .Net 4.0 in your App.config by adding:

<configuration>
<startup>
<supportedRuntime version="v4.0" />
</startup>
</configuration>

In case you have third party components you also have to mark them as being ready for 4.0:

<configuration>
...
<runtime>
...
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
...
<dependentAssembly>
<assemblyIdentity name="AssemblyName" publicKeyToken="31bf3856ad364e35"/>
<bindingRedirect oldVersion="3.5.0.0-3.5.0.0" newVersion="4.0.0.0"/>
</dependentAssembly>
...
</assemblyBinding>
...
</runtime>
...
</configuration>

The source: wpf - BackwardcCompatibility of .NET Framework 4 - Stack Overflow

Read this blog: Multi-Targeting Support (VS 2010 and .NET 4 Series) - ScottGu's Blog

I think that I am right! But I accept that I may well not be.

You are correct as far as coding these things is concerned, but the issue here is not coding. Normal users don't code anything at all, they just load a program and expect it to work. On Windows 7 they do not need to know about any of this, because it is not relevant.

I hope that we can make a good debate out of this, because it is a very interesting topic.

I agree up to a point, and that point is basically that if we are going to discuss coding for .net applications, which I would have to pass on anyway as I simply don't know enough about it to hold a sensible discussion, then the parameters are completely different to a discussion on what normal users have to do to get an application to run on their machines.

In the majority of cases, nothing at all, because all required versions of .net framework are integrated by default. In an increasing number of cases, ( as more applications are actually coded for 4.0), then you have to download the standalone installer and install the full .net 4.0 version or they wont work.

Richard

Regards....Mike Connor

 

[Mike Connor]

Hello Mike!

I bow down to you, I may well be very wrong.

I would much prefer it if you did nothing of the sort! As I already wrote this is not really a question of being right or wrong, It is a matter of using the correct parameters.

However, may I just confirm a few things for my own knowledge?

The only bit you are disagreeing with is whether a .net 3.5 application will run on .net 4.0. Is that the only bit you are disagreeing with, or is some of the rest incorrect as well?

I am not disagreeing with that, or indeed any other of your comments regarding the actual internal workings of various .net Framework versions or their compatibility. I have no doubt whatsoever that your comments in this respect are absolutely correct. The problem is that none of that makes much sense to a normal user, it is also completely irrelevant, because he can not influence it in any way. Long and involved explanations from the point of view of a coder are largely irrelevant to users anyway, and in this case, your declared target was to give a clear explanation of the matter. All you did was muddy the waters with material which although it may be correct in itself, is completely irrelevant to a user on Windows 7.

He does not need to install anything at all for .net compatible versions up to 3.5.1 indeed it is not possible! They are integrated by default. he also does not need to know anything at all about the internal workings of these things. Explaining various code dependencies to a user is absolutely pointless, and merely confuses him.

Thanks a lot!

Richard

Regards....Mike Connor

 

[niemiro]

Good day to you, Mike.

Thanks a lot for the run down. I agree that these ideals are often not adhered to. Look at the problems Microsoft have had with people hardcoding to "C:\Program Files" for example. And they have provided Environmental Variables for ages.

I find the idea of people having to download .net 4.0 by themselves shocking...but then again I spend hours and hours checking security and environmental variables and good practices and the like. My installers always download if required (and it is easy! I only use a suitably licensed free plugin, so I don't exactly have to do a lot of work, just set a flag (ie download .net 4.0 (client or Extended, whatever I set the next flag to be) if required) and it is really neatly fully integrated into the main installers progress bar)

But it is a sad fact that most programmers do not do this. I also completely take your point that to an extent it should be up to the user to get global libraries installed (especially really common Microsoft ones) and I certainly never properly bundle it into the installer.

I should have mad it clearer that when I said what Vista and 7 bundle (3.0 and 3.5.1 respectively), I should have made it clearer that my "Uninstall 2.0 will ruin 3.0 and 3.5" was all hypothetical, and that they are built into Windows, you can't do this, etc. etc. That was my mistake.

Therefore, I usually do target 2.0 in my programs (on the occasions which I use .net) because then I can avoid much of this hassle.

and none of it which I have used to date included the necessary files to run them.

I certainly shouldn't have called them "Bad" applications. I hope that you will accept my sincerest apologies for that, but I like to follow best practices, and the idea that the don't shocks me.

Do you have any more particular issues which I have missed? I can't see any more disagreements any more, can you? Because I think that a fair amount of the confusion stemmed from my poor wording at times. I think we basically agree now, don't we?

Have a great day!

Richard