[ZEUS__]

I created and tested my add-on. thanks everyone..

BTW, I don't know if someone told it before but;

if you want to verify your installations of addon try this;

.NET Framework Setup Verification Tool

This post has been edited by ZEUS__: 15 October 2010 - 12:39 PM

[lejon89]

I create my .net aio exe but i see a problem like this..

I can execute this file only windows xp and i can't see any option for windows 7 or general option.If i can't tell please look picture

This is error



and This is my ini files options

TARGETOS=XP
T13ADDONS=YES
ROEADDONS=YES
ALSOINSTALLERS=YES
MERGEFXS=YES
SILENT=YES
COMPRATIO=HIGHER

[Escorpiom]

lejon89, on 16 October 2010 - 06:38 PM, said:

I create my .net aio exe but i see a problem like this..

I can execute this file only windows xp and i can't see any option for windows 7 or general option.If i can't tell please look picture

Read the title of this topic:

Silent .NET Maker synthesized 20100118 - W2K/XP/2K3 x86

It is not for Windows 7, besides Windows 7 has .Net framework already included.

Cheers.

This post has been edited by Escorpiom: 16 October 2010 - 10:08 PM

[lejon89]

okey,How to make .net 4 for Windows 7 ?

[Sp0iLedBrAt]

You can run it through RunOnce with switches, or use those switches to make a switchless installer with 7-Zip, WinRAR (shareware) etc.

Here are the switches
 dotnet4setup.JPG (77.38K)
Number of downloads: 55

[bphlpt]

Just to give everyone a heads up, since strel has been MIA now for quite awhile, I'm making an attempt to update this script. I've gotten a LOT of help from gora and YumeYao so far, but I'm always very happy to get all the help I can from anyone who is willing/able to help.

Some Questions/Comments:

1) Anyone still using this script for Win2K? - My2GirlsDad did if I remember right.

2) I'm fixing the script so the work arounds that Mooms, SunLion, & Escorpiom came up with will not be required.

3) The IExpress method that krose came up with to handle the multiple embedded hotfix issue will also not be required.

4) I'll update the advice section to current so recently superseded hotfixes will be taken care of.

5) I'm looking at the posibility of adding the ability to add .NET 4 with this method - NO PROMISES - I know several other methods seem to have a few issues with XP and slow start up, so if I can't come up with a way that works, I won't add it.

6) I'm looking at the posibility of adding the ability to handle Win7 (for .NET 1.1 and .NET 4 ONLY) with this method - NO PROMISES

7) I'm very curious why I can't recall anyone asking strel about adding the capability for using this method for x64 - no interest at all? It should work, but I don't even have a x64 capable system, so I would need a LOT of help with testing. It would also help to be able to see someone else's x64 addon that works to see what they did and possibly use it as a model for what my result needs to look like. I might play with this, but - NO PROMISES

8) I'll TRY to add the improvements that are possible with this method that YumeYao has implemented, but again - NO PROMISES

9) I would really appreciate being able to bounce some questions/ideas off anyone who might know just a little bit about this script and it's inner workings, especially concerning the use of the many different versions of KB960043 that have come out and when to use which version. Any help out there, PLEASE??? It would really speed things up as to when I can get this script reworked. If you don't have any idea what I'm talking about, don't worry about it. I'll get it figured out eventually. I'm just the kind of guy that has to understand WHY it works, not just that it does.

Some of the other members here have really been great about taking up the slack in strel's absence to help everyone with their problems. Just to mention a few, Mooms, SunLion, Escorpiom, My2GirlsDad, -X-, gora, YumeYao, Sp0iLedBrAt, Kurt_Aust, krose, and user_hidden among others I'm sure I've forgotten. This script would not have survived without the help of members like this.

I'll try to keep you updated with my progress. If there are any questions, comments, suggestions as to what you would like to see added, changed, or taken out, NOW is the time to make them.

Cheers and Regards

[Sp0iLedBrAt]

If you need someone to test, PM me.

Cheers

[Escorpiom]

Wow bphlpt, that's great news! I would be happy to test your work too.
Please reconsider .Net 1.1 for Windows 7, that's rather old and most apps moved on to 2.0 or higher.
But the .Net 4 is perfectly fine for Win XP or Win 7.

I hope you succeed in updating the script. Awesome.
Edit: No Win2K support needed here.

Cheers.

This post has been edited by Escorpiom: 21 October 2010 - 02:38 AM

[SunLion]

bphlpt,

How excellent notice!

All we will be very grateful for this its initiative. Also, we will look for to help in what it will be to our reach.

Success!

Cheers

[bphlpt]

As I'm trying to update strel's SNMsynth script I have become very confused about KB960043 and it's use. I'm looking for AN"YONE that can shed just a little light on it for me.

I have downloaded and examined ALL the .NET hotfixes I could find on thehotfixshare.net. I have found SIX different versions of NDP35SP1-KB960043.msp BEFORE M$ finally designated them NDP35SP1-KB960043-v3.msp (only used for NDP20SP2-KB972848.msp that I've found) and NDP35SP1-KB960043-v4.msp. The widest variety of versions is used for .NET 2.0. The hotfix is always named NDP35SP1-KB960043xxx.msp regardless whether it's intended to be applied to .NET 2.0, 3.0, or 3.5.

For .NET 3.0 and 3.5 strel handled it this way:
1) Create an administrative install point.
2) Don't apply hotfixes that have been superceded.
3) Sort the remaining hotfixes that apply to that framework (incorrectly, but I know a way to handle that issue).
4) Apply the GDR branch hotfixes (those that have no version of KB960043 included) in numerical order.
5) Apply NDP35SP1-KB960043.msp (if included with any hotfix) then apply the hotfixes that included it in numerical order. [If there were more than one version of NDP35SP1-KB960043.msp involved, it's not clear to me which one was used and if it matters.]
6) Apply NDP35SP1-KB960043-v4.msp (if included with any hotfix) then apply the hotfixes that included it in numerical order.
7) Apply language packs.
etc, etc
NOTE: If the right hotfixes are there, then BOTH NDP35SP1-KB960043.msp AND NDP35SP1-KB960043-v4.msp will be applied.

For .NET 2.0 it's similiar but a little more complicated. The differences are in step (5) and (6). A few of the hotfixes, even if distributed with one of the later versions of NDP35SP1-KB960043.msp, are not applied until after NDP35SP1-KB960043-v4.msp is applied, but if and only if there are other hotfixes present that use one of the earlier versions of NDP35SP1-KB960043.msp. If NDP20SP2-KB972848.msp is present, then NDP35SP1-KB960043-v3.msp is applied first, unless there are other hotfixes present which need NDP35SP1-KB960043-v4.msp, then NDP20SP2-KB972848.msp is applied with them and NDP35SP1-KB960043-v3.msp is not used. It might even be more complicated than that, depending on the exact hotfixes present, but that's what I can wrap my head around so far. This seems extrordinarily convoluted.

What's the difference between KB960043, KB960043-v3 and KB960043-v4? I can't find any discussion by M$ that even acknowledges that there ARE different versions much less explains their differences and which ones are used when and why. And it doesn't seem right to apply BOTH NDP35SP1-KB960043.ms AND NDP35SP1-KB960043-v4.msp.

Would it be OK to always just use KB960043-v4?

Would it hurt to always apply NDP35SP1-KB960043-v4.msp to .NET 2.0, 3.0, and 3.5 even if it wasn't necessary?

YumeYao has explained to me that "KB960043 doesn't contain any actual file inside it, it mainly changes the "UpgradeCode" of a specific product(2.0/3.0/3.5). In this way, the LDR branch can be applied upon it." If this is true, then it seems that it really only effects the administrative (or regular) install, and not the hotfix it is distributed with, so why can't I just use NDP35SP1-KB960043-v4.msp?

If I could do that, then I would think a revised build scenario could be:
1) Extract all hofixes, that have not been superceded, in correct numerical order, overwriting any xxxxx.msp with a earlier date code.
2) Resort, in correct numerical order, by framework.
3) If any version of KB960043.msp is present, use only the latest and delete the others, or even force the use of NDP35SP1-KB960043-v4.msp.

Then for each framework:
A- Create an administrative install point.
B- Apply NDP35SP1-KB960043-v4.msp if present, or do it all the time if that would not cause a problem.
C- Apply the framework hotfixes in correct numerical order.
D- Apply language packs.
etc, etc

The revised step (1) is almost necessary now as a general build process since M$ has started distributing hotfixes that apply to more than one framework, such as NDP30SP2-KB982168-x86.exe, if I don't want to have to handle special cases.

If nothing else, I can just try it, but then how can I tell if it worked, since the effected hotfixes are generally request only and wouldn't show up on MU/WU even if they weren't installed correctly? Any thoughts, opinions, or advice? I could sure use some.

I look forward to hearing from anyone about this very confusing matter.

Cheers and Regards

This post has been edited by bphlpt: 21 October 2010 - 07:08 AM

[Sp0iLedBrAt]

Quote

Would it be OK to always just use KB960043-v4?

Isn't this how Windows Update basically works?
In absence of actual documentation, all we CAN do is presume the every superseeding hotfix already contains the code included in the previous versions, as well as some repairs done to it. Of course, this will only work if every following version contains the exact files that were in the previous ones.
That's what I do.

bphlpt, I read your PM; hope this helps.

Cheers

[bphlpt]

Sp0iLedBrAt, on 21 October 2010 - 07:33 AM, said:

Isn't this how Windows Update basically works?

In this case, I don't know. Since KB960043 is included inside the hotfix exe that requires its presence, I don't know what WU/MU does when it comes across another hotfix that also has KB960043, but a different version. Is it applied also? Potentially 8 times since I found 8 versions? Only versions 4, 7 and 8, or what? What happens if you use version 8 only, even though the hotfix was distributed with version 1 or 2? I have found NO documentation from M$. As I said, I can try it, but how do we verify it? If I can't find anyone who knows, I guess that's what I'll have to do, but it's frustrating. (But isn't everything M$ does?)

When I get this done I'll have to rely a LOT on you guys to test this.

Cheers and Regards

[Sp0iLedBrAt]

Bear with me for a while:
I recently completely uninstalled a normally installed .NET 3.5 SP1 (including .NET 2.0 SP2 and 3.0) package and installed a modified package (SNMSynth) with included hotfixes (including those made with IExpress using the above mentioned method). Windows Update showed I missed a few packages, so I extracted the .msp files from those hotfixes and tried manually. The first one asked for Netfx30a_x86.msi (would not work with the modified one from SNMSynth, but it did work with the original one from dotnetfx35.exe). In the end, I extracted the files from the other .msp files, renamed them and replaced them manually. This also did the trick.
Conclusion (although it took me a while to get there): Windows Update checks the file version and reports what you need.
BTW, I used the QFE (not the GDR) files wherever possible.

[bphlpt]

Sp0iLedBrAt, on 21 October 2010 - 09:21 AM, said:

Conclusion (although it took me a while to get there): Windows Update checks the file version and reports what you need.
BTW, I used the QFE (not the GDR) files wherever possible.

I'll just have to make sure I do just as good a job as WU since I'll be doing WU's job as I build the administrative installs. Thanks for the heads up regarding WU's sensitivity about Netfx30a_x86.msi as it stands now. I'll try to make sure that is not an issue. One way that comes to mind to check that would be to build a pack but leave out on purpose one hotfix/update and see if WU is then able to add just that one update without complaining about needing Netfx30a_x86.msi. As I get further along, I'm sure that that and other issues will be resolved.

Cheers and Regards

[Escorpiom]

bphlpt,

KB960043 is not really an update. It only sets a flag on the system. It is called dual branch servicing.
I think it's better to paste this text from MS that explains something:

What does Dual Branch Servicing mean exactly?
With Dual Branch Servicing, updates for GDR class releases (updates, cumulative updates, and security updates) will contain two versions of the payload,
a "clean" payload that carries only the security fix but no cumulative hotfixes and a second payload that contains the cumulative hotfixes 
together with the security fix. 

The first "clean" payload would be installed for customers who have no hotfixes applied (most customers) and the second cumulative payload 
would be installed for customers who do have one or more hotfixes installed. 

How does Dual Branch Servicing work?
When a customer installs a hotfix, the update is installed together with baseliner update 960043. 
This baseliner is like a flag in the computer that tells future updates for that product that a hotfix is present. 

In the future, when the customer installs a GDR-class update (including a security update), that update looks for the baseliner. 
If the baseliner is not present because no previous hotfix was installed, the payload from the GDR branch is installed so that the hotfix is not included.

If the baseliner is found, then the payload from the LDR branch, such as the cumulative binary that includes a hotfix, is installed. 
This model prevents the installation of the GDR for customers who have hotfixes installed.

The advantage of this model is that if you install a GDR first, the GDR payload will then be applied. 
If you then install a hotfix, and the baseliner is present, the GDR will be automatically switched from the GDR branch payload to the LDR branch payload. 
This prevents a regression of the hotfix.

Most probably you've already read that.

I think because we are making a complete installer instead of updating previous framework installs, you'll be OK with the last version of the baseliner. No need to install previous versions.

Cheers.

[Sp0iLedBrAt]

[/quote]Thanks for the heads up regarding WU's sensitivity about Netfx30a_x86.msi as it stands now[/quote]
Let me make myself clear as much as I can. Netfx30a_x86.msi was required by the .NET 3.0 .msp files which don't install correctly through SNMSynth, and they are the same ones that have to be extracted and repacked with IExpress. Those didn't install properly (even when repacked) with SNMSynth, so I started them manually and discovered this interesting fact, i.e. their dependency with the unmodified Netfx30a_x86.msi.
As a consequent result, they won't install from Windows Update either.

Hope that helps.

[bphlpt]

Anyone out there use the Request only hotfixes? I'm looking at the logic needed to be able to advise the user which have been superceded by what. strel didn't do this and I'm beginning to see why. Some of them are quite intermingled and overlapped so it's not at all a straight forward decision. It would be a lot easier to figure that if it's request only then the user is responsible for deciding whether to put it in there or not. If it's there it will get ingtegrated, which is essentially what strel did. Problems with that? Does anyone care?

Has anyone used NDP1.1sp1-KB946922-X86.exe? The exe and msp are both named NDP1.1SP1xxxxx, but the info from M$ about KB946922 says that it applies to .NET 2.0. I'm tempted to believe M$, but I'm more likely to either ignore it if it's there, or again since it's a request only hotfix apply it even though I don't think it's right and let the user be responsible. Opinions?

Any other requests for changes/additions/subtractions? NOW is a good time to let me know.

Cheers and Regards

This post has been edited by bphlpt: 23 October 2010 - 10:55 AM

[SunLion]

My opinion is of that the updates must consist of script the integration of all, also the optional ones, that they could be added for in agreement integration the interest of each user.

Cheers

[bphlpt]

A better example of what I meant is:

We start out with:

Quote

17-Nov-2004 06:57 1.1.4322.2048 2,138,112 Mscorlib.dll
16-Nov-2004 03:28 1.1.4322.2048 2,514,944 Mscorsvr.dll
07-Dec-2004 03:29 1.1.4322.2048 2,506,752 Mscorwks.dll

Then KB890340 says it changes only:

Quote

07-Dec-2004 20:27 1.1.4322.2053 2,138,112 Mscorlib.dll
07-Dec-2004 20:27 1.1.4322.2053 2,519,040 Mscorsvr.dll
07-Dec-2004 20:30 1.1.4322.2053 2,506,752 Mscorwks.dll

Then KB893251 says it changes only:

Quote

25-Mar-2005 23:34 1.1.4322.2310 2,138,112 Mscorlib.dll
31-Mar-2005 02:37 10,916 Mscorlib.ldo
29-Mar-2005 18:48 1.1.4322.2310 2,519,040 Mscorsvr.dll
29-Mar-2005 18:48 1.1.4322.2310 2,506,752 Mscorwks.dll

Then KB899181 says it changes only:

Quote

06-May-2005 22:37 1.1.4322.2323 2,138,112 Mscorlib.dll
06-May-2005 22:39 10,904 Mscorlib.ldo
06-May-2005 22:48 1.1.4322.2323 2,519,040 Mscorsvr.dll
06-May-2005 22:49 1.1.4322.2323 2,506,752 Mscorwks.dll

Then KB900822 says it changes only:

Quote

09-Jun-2005 05:46 1.1.4322.2331 2,138,112 Mscorlib.dll
09-Jun-2005 05:48 10,908 Mscorlib.ldo
09-Jun-2005 05:56 1.1.4322.2331 2,519,040 Mscorsvr.dll
09-Jun-2005 05:57 1.1.4322.2331 2,506,752 Mscorwks.dll

and it continues with 922542, 924421, 927495, 935224, 942228, 953297, 979906, and 2416447 all having later editions of those four files. So my thought was, if I could figure all the interactions out, if you have one of the later files, there is no need to apply the earlier ones because they will get overwritten anyway. strel already does this with the "standard" updates - he only applies the latest, if it supercedes an earlier file. But the request only hotfixes are VERY intermingled so it's complicated. Other opinions?

Cheers and Regards

This post has been edited by bphlpt: 23 October 2010 - 01:10 PM

[Sp0iLedBrAt]

Here's one: I think you should create a poll and see how many of the users out there actually use those hotfixes. My opinion is that most of the people that use SNMSynth here are just end-users like me (and I have no idea what those specific hotfixes are for, in spite of the elaborate explanations), that use .NET just for application compatibility.

I was going to ask if request-specific hotfixes were superseded by any normally released hotfix, and then I found this on page 1:

Quote

These hotfixes are not deployed through win/ms update or direct ms download link, but only after asking MS for them. They are not needed to stop update system prompting .NET hotfixes. They fix uncommon errors, may be not fully tested, and ocassionally may be included on future regular updates, so up to you to use them or not.

I tried one of them once (can't remember which one), and it integrated successfully; at this point many of those could very well be replaced by regular updates.

Cheers