Archiv für die Kategorie 'Deployment'

.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

Errors after Installing Dev10 Beta2 over top of Beta1 on Vista RTM or SP1

Monday, 19. October 2009 at 11:01 pm

There is an issue upgrading .NET 4.0 from Beta1 to Beta2 only on Vista RTM and SP1 as well as Windows Server 2008 SP1. This is due to a known issue that was fixed in Vista SP2, Win7, and Windows Server 2008 R2. It is not an issue on XP.


There is a document available here for how you avoid the problem and directions for how to recover if you are already in a bad state.


 

Original post by Petermarcu

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

WiX: Removing Files with Patches

Wednesday, 20. May 2009 at 8:17 am

I’ve had numerous people ask me how to remove a file using a patch. As I say below again, this should be done carefully.

 

Background



If a file is present in a Baseline package then removed in the Upgrade package, it is not trivial to get the installer to remove the file in a way that uninstalling the patch will put it back.

 

Important!!! MUST READ

 

Before removing a file you need to make sure you have no other options. The only time you should remove a file using a patch is when the mere presence of the file causes problems. Consider removing references to the file from files that use it or patching it to be an “empty” file. Removing a file should be a last resort.

 

For shared files, removing a file with a patch could mean breaking any other product using that file. The removal of the file does not take reference counting into account when determining to remove a file. It will be removed if you tell it to be removed. Make sure you consider everything that uses or could use the file before removing it.

 




If a file must be removed by a patch there are a few options:


If the file is not a the keypath of its component:

- Remove the file from the component
- Add a RemoveFile entry to the component.


If the file is the keypath if its component:


If the file is the keypath, it means this file is the identity of the component. In this case the entire component must be removed. You cannot simply remove a component using a patch. If you do, you have to remove the entire feature which is not usually the desired scenario. If it is, then just remove the feature from your patch.


In order to remove a component without removing its feature you need to convince Windows Installer that the component isnt supposed to be installed but the msi database still needs to know about it. You can achieve this by making the component’s condition false. In order to cause a recalcalculation of the component during repair/patch you also need to mark the component as transitive. The side-affect of this is that when the patch is uninstalled, the file is not put back on the machine. This is because when the patch is removed, the component is no longer transitive and its condition is not reevaluated. You can solve this by shipping two patches. One that marks the component as transitive and a second that makes the component’s condition false.


Example:

<Component Id=”Foo” Transitive=”yes” … >
    <Condition>FALSE</Condition>
      …
</Component>


Notes and considerations:


In any case, uninstalling the patch may prompt for source if the file that needs to be put back is not available to the installer.


If building 2 patches for the transitive solution, you cannot base the two patches off of the same build because both changes are made to a single component which is the smallest level at which patches can be filtered. 

Original post by Petermarcu

Abgelegt von Deployment, Setup, Peter, Marcu, WiX
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
« vorhergehende Beiträge