Cool! I stand corrected on if symbols are loaded in this situation. Symbols are not loaded in the traditional symbol server sense of <path>\file.pdb\<GUID>\file.pdb approach. I'm so used to thinking of the symbol server that way I didn't see that just setting _NT_SYMBOL_PATH=c:\syms will be searched as well. I humbly have withdrawn my previous mail. :)
John Wintellect http://www.wintellect.com +1-877-968-5528 -----Original Message----- From: Mark Modrall [mailto:mmodr...@mzinga.com] Sent: Friday, February 11, 2011 5:12 AM To: General discussion for Windows Installer XML toolset.; John Robbins Subject: RE: [WiX-users] Wix and "tricky" environment variables That's a very good question, Ed. I've only tested it on our boxes, and we only ever have 1 rev of our code there at a time. Don't know what would happen if we started installing multiple versions, but thanks for making that point. Mark -----Original Message----- From: Maillet, Ed [mailto:email...@unum.com] Sent: Friday, February 11, 2011 8:06 AM To: General discussion for Windows Installer XML toolset.; John Robbins Subject: Re: [WiX-users] Wix and "tricky" environment variables Doesn't that only work if you have one version of an assembly? Two Acme.dlls (v1 and v2) in the gac present a problem, doesn't it? -----Original Message----- From: Mark Modrall [mailto:mmodr...@mzinga.com] Sent: Friday, February 11, 2011 7:19 AM To: John Robbins; General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Wix and "tricky" environment variables Hi John... Actually, putting your .net pdbs in _NT_SYMBOL_PATH *does* work; that's why I'm trying to do it. http://blog.softwareishardwork.com/2010/02/enable-stack-trace-line-numbers-in.html I came to adding it to my installers after proving that it worked by doing it manually. Your note about keeping the pdbs in reserve for performance reasons is a good one, and I'll keep that in mind. Thanks Mark -----Original Message----- From: John Robbins [mailto:j...@wintellect.com] Sent: Thursday, February 10, 2011 10:33 PM To: General discussion for Windows Installer XML toolset.; Mark Modrall Subject: RE: [WiX-users] Wix and "tricky" environment variables Mark, As someone who's concentrated on debugging and debuggers his whole career, it warms my heart to hear people talking about _NT_SYMBOL_PATH. :) However, _NT_SYMBOL_PATH is only used by debuggers. The .NET StackTrace class, which is generating the call stacks in your exceptions, will only look for the PDB files in the same directory as the .EXE. So even if you add this to your installer, you still won't get source and line information on any exception stack trace. Also, I recommend that you keep the PDB file installer separate from the main installer. As there's extra file I/O and overhead for reading the PDB files when the exceptions are thrown, you only want to install the PDB files when you are certain you've got a problem and need that information. Hope it helps! John Wintellect http://www.wintellect.com +1-877-968-5528 -----Original Message----- From: Mark Modrall [mailto:mmodr...@mzinga.com] Sent: Thursday, February 10, 2011 6:13 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Wix and "tricky" environment variables Well, you caught me flat footed with the App Path stuff, so I could be misunderstanding the Symbol Server stuff :) But here's my understanding of what that's about: 1) Microsoft has a public service that will vend .pdb files for Microsoft components and you can set _NT_SYMBOL_PATH to pull from there 1a) You can set your _NT_SYMBOL_PATH to cache the results from Symbol Server locally if you want with a special syntax 2) If you're using a debugger and interactively watching something, you can use Symbol Server directly without _NT_SYMBOL_PATH 3) For your own symbols you're on your own. Though I gather from your question (SDK vs internal process), there may be a way to register your symbols in the Microsoft Symbol Server. I might be missing something, but it doesn't seem like you can get away from _NT_SYMBOL_PATH entirely. At the least you have to register your symbols with Microsoft and set _NT_SYMBOL_PATH to point at the server. Our use is for logging exception stack traces in a database, not hands-on interactive debugging. The problem is that when you put things in the GAC it's considered bad form (and somewhat convoluted) to put the .pdbs in the GAC too. If the pdbs are lying right next to the .exes and .dbgs, you don't need to use _NT_SYMBOL_PATH because the default behavior checks the immediate environs before looking in the paths defined in _NT_SYMBOL_PATH. Alas the GAC messes that up. We've always been dumping the .pdbs in our install directory but the stack traces that get logged blank out on anything that's gone through the GAC because the executables aren't located there. Another frustrating thing about the gac is that even if you have a copy of the executable, say, in the /bin directory of your ASP.Net application it's going to use the GAC version instead and not infer anything about where your symbols might be from the one in your /bin directory. So we're down to getting _NT_SYMBOL_PATH set properly in our installer. But not wanting the installer to keep accreting our directory on the front/back every time we install. And not destroying an environment variable that's a shared resource in the process, which is why I'm trying to form the right test in Wix to see if we're already in there. In our case, we're a saas provider, installing our stuff across a farm of ~100 of our servers. We're not a re-seller or SDK vendor. We're just trying to manage our farm. Thanks Mark -----Original Message----- From: Christopher Painter [mailto:chr...@deploymentengineering.com] Sent: Thursday, February 10, 2011 8:50 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Wix and "tricky" environment variables I'm no expert wrt to symbols so treat this advice as an old drunk sailor sitting at the bar telling a story..... :-) I did a google search and a lot of people seem to not like _NT_SYMBOL_PATH. There seems to be some good things to be said about Symbol Server. Can I assume that your installer is some sort of SDK? Or are you perhaps automating an internal process? Any advice given would depend on the answer to that question (e.g. does the end user want to contol his own destiny or is it a captive audience ). However, I'm not going to go there anyways because I'm just an old drunk old sailor today. (PS- No offense meant for any squids that might be out there. Oorah ) --- Christopher Painter, Author of Deployment Engineering Blog Have a hot tip, know a secret or read a really good thread that deserves attention? E-Mail Me ----- Original Message ---- From: Mark Modrall <mmodr...@mzinga.com> To: General discussion for Windows Installer XML toolset. <wix-users@lists.sourceforge.net> Sent: Thu, February 10, 2011 7:39:08 AM Subject: Re: [WiX-users] Wix and "tricky" environment variables Hi Chris... Thanks for the tip on App Path; I didn't know about that one. Unfortunately, I used PATH as an example because I thought that's the one people would be most familiar with, but there are a number of environment variables that function similarly. My own fault for not being more direct. What I'm actually trying to maintain is _NT_SYMBOL_PATH. I'm trying to add the directory where my .pdbs live so that my GAC'ed components can still get symbol info in stack traces. _NT_SYMBOL_PATH works similarly to PATH in terms of syntax and function and Wix would act on them pretty much the same way. Mark -----Original Message----- From: Christopher Painter [mailto:chr...@deploymentengineering.com] Sent: Thursday, February 10, 2011 6:50 AM To: General discussion for Windows Installer XML toolset. Subject: Re: [WiX-users] Wix and "tricky" environment variables I'll be honest, it's 2011 and I'm hard pressed to understand why software applications still cling to the need to be in the "PATH"... a concept that originated some 30 years earlier. Can you redesign your application to not need to be in the path? Or, can you use AppPaths to make certain executables and http://www.sepago.de/d/helge/2010/08/26/how-the-app-paths-registry-key-makes-windows-both-faster-and-safer Otherwise, I'd suggest that if the built in Env@Part First|Last isn't working that you could change it to All and then use a custom action to do your own parsing ( dedupication, sorting, appending and so on. ) I'd test it really good though because I've never done this and I'm not sure what the gotchas would be. --- Christopher Painter, Author of Deployment Engineering Blog Have a hot tip, know a secret or read a really good thread that deserves attention? E-Mail Me ----- Original Message ---- From: Mark Modrall <mmodr...@mzinga.com> To: General discussion for Windows Installer XML toolset. <wix-users@lists.sourceforge.net> Sent: Wed, February 9, 2011 2:58:40 PM Subject: [WiX-users] Wix and "tricky" environment variables Hi... I'm looking to get my installer to appropriately set an entry in one of those "tricky" environment variables, like %PATH%. By "tricky" I mean shared and accretive - it's a multi-value crossroads that everybody and their brother will be mucking with. I want to make sure our addition gets in there but don't want to just keep appending our root every time the installer is run. In the same vein, I can't just blank the variable when our product is uninstalled. So I was thinking I'd add a custom action type 51 to get the value into a property and a conditionalized component with a test on the value, but I'm not quite clear on how all the pieces would fit together... Something like <Component Id="SetPath"> <Condition><![CDATA[NOT EnvPath><C:\Program Files\Mypath;]]></Condition> <Environment Id="EnvSetPath" Action="set" Name="PATH" Part="first" Permanent="yes" System="yes" Value="C:\Program Files\MyPath" /> </Component> ... <CustomAction Id="EnvPath" Property="EnvPath" Value="[%PATH]" /> Problem is that all the examples I'm cribbing from are using ellipsis too, so I'm not sure if I have to declare what phase the custom action will be executed in, etc. Am I on the right track? Thanks Mark ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users ------------------------------------------------------------------------------ The ultimate all-in-one performance toolkit: Intel(R) Parallel Studio XE: Pinpoint memory and threading errors before they happen. Find and fix more than 250 security defects in the development cycle. Locate bottlenecks in serial and parallel code that limit performance. http://p.sf.net/sfu/intel-dev2devfeb _______________________________________________ WiX-users mailing list WiX-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/wix-users
