Archiv für die Kategorie 'Peter Marcu'

.NET Framework 4 setup reports success but mscoree.dll is not updated

Thursday, 28. July 2011 at 1:30 am
I’m curious to hear from people that are hitting or have hit this issue.
 
Im particularly curious if trustedinstaller.exe is present under %windir%\servicing\trustedinstaller.exe. This appears to be the main root cause of this issue (at least on the machines I’ve seen). This will help better understand if this is the root cause of all the issues I’ve been hearing about or if there are other root causes.
 
If this is the root of your issue. I would recommend following the steps in this article to try to get trustedinstaller.exe put back http://support.microsoft.com/kb/929833 .
For anyone who hit this and trustedinstaller.exe is present, I’d love to get in touch with you to hopefully find potential other root causes of this issue.

Below are more details about the issue for those of you that are interested.

.NET 4 depends on a Windows Update which is documented in these KB articles:
Win7 = http://support.microsoft.com/kb/958488
Vista = http://support.microsoft.com/kb/956250

Aaron Stebner did a good job in root causing this down to an issue with Windows Update on the machine. He documented his analysis here: http://blogs.msdn.com/b/astebner/archive/2010/12/29/10110053.aspx

The issue here is the .NET 4 is trying to install the update it depends on but Windows Update is, in error, telling the .NET 4 installer that the update is not applicable to the machine. The .NET 4 installer treats this response to mean that is not needed and moves on. In general, if Windows update is returning “not applicable” for and update one of wo things is true. Either its not applicable, or something is really wrong with Windows Update and no updates including critical security updates are able to install.

I took Aaron’s investigation a step further and was able to find a concrete example of where I could get Windows Update to return “not applicable” on a machine where an update should have been applicable. On this machine TrustedInstaller.exe was not present on the machine which is critical for correct behavior of Windows Update.

I then found that there are numerous places on the web that are telling people to disable, remove, or in other ways kill trusted installer. This is a bad idea and appears to be the root cause of a lot of these issues. Products that depend on your copy of Windows being up to date will all exhibit weird behaviors if the update cannot be applied. The workarounds I’m seeing for this issue are scary and likely have unintended consequences such as future updates failing to install and putting your machine in a state that Microsoft can’t support. I dont recommend taking ownership of system files, hacking files out of installer packages and manually updating them.

Original post by Peter Marcu

Abgelegt von .NET Framework, Windows, Deployment, Peter Marcu, Peter, Setup, Marcu
von
Kommentar hinzufügen

.NET: .NET Framework 4 setup reports success but my .NET 4 applications wont run and tell me I need to install it.

Thursday, 28. July 2011 at 1:30 am
I’m curious to hear from people that are hitting or have hit this issue. Leave a comment or contact me directly through my blog.
 
The issue here is often that %windir%\system32\mscoree.dll is not updated as part of the install. Behing the scenes of the installer, .NET 4 is trying to install an update to the OS and that it depends on but Windows Update. Windows update is telling the .NET 4 installer that the update is not applicable to the machine. The .NET 4 installer treats this response to mean that is not needed and moves on. In general, if Windows update is returning “not applicable” for and update one of wo things is true. Either its not applicable, or something is really wrong with Windows or Windows Update and no updates including critical security updates are able to install.
 
So far I have found two root causes of this issue:
 
1. %windir%\servicing\trustedinstaller.exe is not present on the machine.
2. The operating system is not an officially released version of the OS.
 
I’m curious to hear from anyone experiencing this issue. I’d like to know which of this issues it wascor if there is a root cause of this that I have not found.
 
Trouble Shooting/Self Help Instructions:
 
1. %windir%\servicing\trustedinstaller.exe is not present on the machine.
 
If this is the root of your issue. I would recommend following the steps in this article to try to get trustedinstaller.exe put back http://support.microsoft.com/kb/929833 .
If anyone has any idea what would have removed trustedinstaller.exe from their machine, I’d love to hear about it.
 
2. The Operating System is not an officially released version of the OS.
 
You can check this by looking at the version of %windir%\servicing\trustedinstaller.exe or looking in %windir%\logs\CBS\CBS.log. In the log you should see logging lines that look something like this: “Loaded Servicing Stack v6.1.7601.17592″.
 
For Windows 7, I would expect to see a version of at least v6.1.7600.16385. If you see a number lower than this on Windows 7, the only way I know of to fix this issue is to do an upgrade to a supported released version of Windows 7. The more important thing in this case is that pre-release OS’s do not get updated with critical security patches from Microsoft. Thats not a really good situation to be left in, especially if you dont know it.
 
I’ve seen many reports of people having a build number of v6.1.7600.16384 which is one number below the released build. I’m really curious how people would have gotten this build of the OS. The fact that its so close to the final build makes me wonder if it could have been accidentally released somehow. Please let me know if you got it through an official supported channel and its the wrong version.
I’d like to thank Mike Lewis for contacting me and helping me find the 2nd root cause. I’d love to hear from anyone else hitting this issue to make sure I can write down all the causes of this for people.

Original post by Peter Marcu

Abgelegt von .NET Framework, Windows, Deployment, Peter Marcu, Peter, Setup, Marcu
von
Kommentar hinzufügen

.NET: The Client Profile and Chip Specific Packages

Wednesday, 21. July 2010 at 7:22 am

In .NET 4 we have quite a few deployment options available for redistribution. There are basically 2 pivots. The Client/Full profiles and 32bit/32+64bit packages.

Here are the four redistributable options and their corresponding sizes.

Redistributable Size
32bit Client Profile 28.8 MB
32bit Full 35.3 MB
32+64bit Client Profile 41 MB
32+64bit Full 48.1 MB

The Client Profile is targeted to contain the parts of the .NET Framework that are used by most client applications and gives people the option to carry a little less payload if they use less of the Framework.

The 32+64bit packages are designed to give the option of installing either profile on any target machine regardless of OS architecture. On the other hand, if someone is targeting a pure 32bit customer segment, the 32bit package gives the option of reduced size with reduced breath of deployment.

Original post by Peter Marcu

Abgelegt von .NET Framework, Deployment, Peter Marcu, Setup, WiX
von
Kommentar hinzufügen

Which Version of .NET is Built into Windows?

Friday, 5. February 2010 at 6:25 pm

Over the past few years I have been asked more and more which version of .NET is included in the operating system. The following chart shows from .NET 2.0 onward, which version of .NET is included in both the Client and Server Windows operating systems.

image

Note that this diagram also shows which pieces are optional and whether or not they are on by default in that particular OS.

Original post by Petermarcu

Abgelegt von .NET Framework, Windows, Deployment, Peter Marcu, Peter, Setup, Marcu
von
Kommentar hinzufügen

.NET: Do you Deploy a Managed App?

Saturday, 20. September 2008 at 8:16 pm

Do you own the deployment of your product and require the .NET Framework to be installed before you can install your application? If so, I want to hear from you.


I have a few general questions but any comments are welcome as long as they are constructive and actionable. My goal is to use this data to do what I can to improve the .NET Framework Redist experience in future versions.

Do you have a bootstrapper/chainer that preinstalls .NET? If so, which one (VSI, InstallShield, Wise, ClickOnce, custom)?
Do you block and point your user to the location to download and install .NET?
How large is your application?
How is your product deployed (Web download, CD, DVD, USB)?
What do you think about the size of the .NET package?
Do you know about the small package for .NET 3.5 that will download only what your user need? If so, do you use it?
What do you like about the .NET Framework Redist?
What do you dislike about the .NET Framework Redist?
Do you have any specific problems you can tell me about that you have had in deploying the .NET Framework?


Like I said, the info above will be helpful to me but I dont want to limit responses to these questions. We have a lot of data about the various issues people encounter while installing the .NET Framework but we dont have as much data about the ways people are deploying it and using it as part of their deployment. This is the type of info I’m looking to gather.


You can post as a comment or email me the info if you dont want it posted and seen by all.

Original post by Petermarcu

Abgelegt von Deployment, .NET Framework, Peter Marcu, Setup, Marcu, Peter, Visual Studio
von
Kommentar hinzufügen

WiX: Patching something you didnt build with WiX using WiX

Saturday, 31. May 2008 at 1:05 am

Many times people want to take advantage of the Wix v3 patch building features but didnt build their original product using Wix. for example, they may have used Install Shield, WiX v2 or one of the other tools out there. I ran into this when I needed to create a patch for a product we shipped from Visual Studio before the Visual Studio build moved to WiX v3.


 WiX v3 has a feature I added a while back to support this scenario. It allows you to point at an admin image of your msi based install package. This will be very familiar to some of you who have used patchwiz and pcp’s in the past. The difference here is that your patch authoring can be done using the WiX v3 Patch element and it follows the same workflow as patching a WiX v3 based msi after the first stage of creating the diffs.


Something I found really easy, and I could see this being used by smaller products who dont have a lot of infrastructure, is the ability to hand edit your admin image to product the patch. For example, I wanted to update a single file in my product:


1. I created an admin image
2. I made a copy of the admin image
3. I updated the loose file in my copy of the admin image


After running it through the series of command lines, I got a patch that updated the file. Pretty simple…


The command lines you need to run are all the same as the ones in my sample: Building a Patch using the new Patch Building System - Part 3. The only difference is that you need to pass the -ax command with a path to extract embedded binaries to instead of the -xi switch. This tells torch that the input is admin image instead of xml. Also, specify the path to the msi in the admin images instead of the wixpdb as the target and upgrade. Everything after that should follow the same process.


Let me know how it works! :)


Bonus feature: One of the most useful things in the WiX v3 patching system is the ability to filter whats in your patch using patch families to only ship your customers the updates they need. This allows you to grab changes per Fragment from your wix source. When patching from admin images, there is no source so you would think that the filtering isn’t suppoted. Not so! This was one of the more fun parts of this implementation. We “auto-fragment” the msi into what we consider to be the optimal chunks to give you the ability to filter if you choose to do so.

Original post by Petermarcu

Abgelegt von Peter Marcu, Deployment, Setup, Peter, Marcu, WiX
von
Kommentar hinzufügen

WiX: Introducing the WixPdb

Monday, 26. May 2008 at 8:35 am

I should have made this post about 6 months ago as I was implementing the WixPdb feature in WiX but better late than never :).  The wixpdb was conceived as a solution for a limitation in the original patch building system. Originally, WiX v3 patching only supported creating transforms between two wixout files. This was flawed in that many things modify the output after the wixout is generated by light which weren’t being reflected in patches. I knew I needed the patch build system to be able to create transforms from something closer to the final output. Thats what the WixPdb is. It is all the data in the output right before creating the final msi. With that data, we can now create more accurate transforms to what people expect when diffing two products. I updated my blog with samples on how to build patches to show that I now recommend using the wixpdb instead of the wixout.


Down the road, I look forward to seeing what other features we can get out of the wixpdb. It provides a ton of information an allows you to potentially connect install time errors all the way back to the wix source and line number. Static analysis is another benefit. I updated smoke to be able to take the wixpdb so it will give you source and line number information for ICE errors. Statis analysis on the wixpdb itself may also be interesting because it contains more data than in the msi. It is the one place where the wix source data and the msi data connect. Let me know if you have any ideas of how to use the wixpdb in some cool ways…

Original post by Petermarcu

Abgelegt von Peter Marcu, Deployment, Setup, Peter, Marcu, WiX
von
Kommentar hinzufügen