Archiv für die Kategorie 'Setup'

AppX has no custom actions.

Thursday, 15. September 2011 at 6:22 pm

I didn’t plan to start my discussion about the new installation technology in Windows 8, AppX, with this topic. However, a quick scan through this morning’s email from wix-users prompted me to start here.

Read More…

Original post by Rob Mensching

Abgelegt von Setup
von

Setup in Windows 8 and Visual Studio.

Wednesday, 14. September 2011 at 8:50 am

I joined the Developer Division almost 2 years ago. When I announced the move I spoke about my new focus on the short and long term of setup on Windows. In the Windows 8 keynote and the Developer Preview bits available now you can see the results of both. It all starts in the keynote when Antoine Leblond comes on stage and fires up Visual Studio.

Read More…

Original post by Rob Mensching

Abgelegt von Setup
von

.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

von

.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

von

ARPINSTALLLOCATION and how to set it with the WiX toolset.

Friday, 14. January 2011 at 5:22 pm

There is a property in Add/Remove Programs (called "Programs and Features" in Vista+ but setup developers in the know call it "ARP") that can specify the install location for your application. Like most properties in ARP, it’s questionable what value InstallLocation provides. However, it’s there and some things look for it and the Windows Installer provides a standard way to set it, so let’s talk about how to do so with the WiX toolset.

Read More…

Original post by Rob Mensching

Abgelegt von Setup, WiX
von

The first thing I do with an MSI log.

Tuesday, 3. August 2010 at 6:27 am

If you’ve dealt wit the Windows Installer at all, you know the fastest way to figure out what went wrong is to look at a verbose log file. The normal log file doesn’t provide enough information to really diagnose things going wrong, so I always generate a verbose log file like so:

Read More…

Original post by Rob Mensching

Abgelegt von Setup
von

.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

von

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

von