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:[email protected]]
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:[email protected]]
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:[email protected]]
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 <[email protected]>
To: General discussion for Windows Installer XML toolset.
<[email protected]>
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:[email protected]]
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 <[email protected]>
To: General discussion for Windows Installer XML toolset.
<[email protected]>
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
[email protected]
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
[email protected]
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
[email protected]
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
[email protected]
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
[email protected]
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/wix-users
