It's me again :)
As nobody seems to be able to answer my question, I'll try to rephrase it ...
There has to be a way to write unit tests against customs actions made with dtf.
If not, stop me right here ... because if I can't, I'd have to use something
else and drop dtf, which would be a shame a
Thanks guys,
I'm installing mercurial to get a checkout as we speak :)
-Original Message-
From: John Robbins [mailto:j...@wintellect.com]
Sent: Monday, November 28, 2011 04:37
To: General discussion for Windows Installer XML toolset.
Subject: Re: [WiX-users] UI in WPF
Also, look at the
H... first of all, personally I'm not soo deep in c#. But did some
unit testing against DTF code. It's ugly.
Use a mapping of the external session object to an internal and do all
the tests against the internal "session object". The communication to
the outer world then is limited to a small c
Well, our main product is mostly a bunch of web services. Each web service
lives in its own AppPool. So, in upgrade scenarios, I have a custom action
that harvests the account and password for the AppPool directly from IIS7.
It's been a while since I've worked with pure Windows services, but
I suspect this is a bug fixed in the October 28 build. However, this build is
no longer posted or at least I can't find it. I understand I can download
the source but I can't get a version to build from source.
Has anyone else witnessed this problem with burn application upgrades?
Is there any wa
http://datamexlp.zxq.net/holidays.php?uid=73&detail=161&item=34
--
All the data continuously generated in your IT infrastructure
contains a definitive record of customers, application performance,
security threats, fraud
Bob,
You're exactly right in each of your comments. But they don't address
the root cause of the problem. The error messages I was receiving were
"red herring" messages. It seems I ran afoul of differences in the way
WiX3.5 and WiX3.6 interoperate with Visual Studio.
Starting with a large proj
http://wix.codeplex.com/releases/view/75656 doesn't have the release
from the 28th. I did note that someone was mirroring the releases at
http://madbutcher.dyndns.org/snippets/WiX/ which appears to have a
3.6.2221.0 zip file that may help you. (It appears the zip contains the
installer, source, bin
I'm trying to pass variables into a burn bundle like this:
MyInstaller.exe SOME_VARIABLE=true
I found a thread saying that variables passed into a burn bundle are given to
the BootstrapperApplication, which may create variables from them. I'm using
WixStandardBootstrapperApplication.RtfLicense
The reason is that we already have a file project in place that is
storing all of the custom actions that are used for the project. I'm
not overly allowed to change any of the parameters, except by figuring
out how to link to the wcautil library, which I'm working on again now
that I'm no long
The wixstdba doesn't parse anything from the command line today.
On Mon, Nov 28, 2011 at 11:50 AM, Ian Williams wrote:
> I'm trying to pass variables into a burn bundle like this:
>
> MyInstaller.exe SOME_VARIABLE=true
>
> I found a thread saying that variables passed into a burn bundle are given
Hmm, can you diff the working v3.5 and working v3.6 projects to see what
was not handled correctly? WiX v3.6 should be able to handle WiX v3.5
projects (although harvesting will no longer work).
On Mon, Nov 28, 2011 at 9:56 AM, David P. Romig, Sr. wrote:
> Bob,
>
> You're exactly right in each o
I'd suggest downloading the latest WiX source and including the files
in "src\ca\wcautil\". I'd also have to bet it's going to look for some
files in "inc\". (At the very least, create a new empty C++ CA DLL to
get the templated hooks in the right spot for your DLL. Specifically
looking at the
I've got everything linked properly. However, I'm now getting can't
convert LPWSTR * to const wchar_t * on the following section of code:
if(wcslen(userName) == 0)
{
hr = WcaSetProperty(L"UserInfoError", L"Please enter
your name.");
WcaLog(LOG
LPWSTR is already a wchar_t *, so LPWSTR is a wchar_t **. Hence it is
complaining that it cannot convert a wchar_t ** to a wchar_t *, which makes
sense. It seems to me that you need to change your "LPWSTR *" type to just
"const LPWSTR", or do you not have control over that data type?
Dan
-
Here's the whole of the function:
UINT __stdcall VerifyUserInformation(
__in MSIHANDLE hInstall
)
{
LPWSTR userName = NULL;
LPWSTR email = NULL;
HRESULT hr = S_OK;
UINT er = ERROR_SUCCESS;
hr = WcaInitialize(hInstall, "VerifyUserInformation"
That's probably my fault. Leave the types as they originally were and
use an ampersand in front. Ie:
hr = WcaGetProperty(L"UNAME", &userName);
-Original Message-
From: Kevin Hebert [mailto:ke...@legendary-immersion.com]
Sent: Monday, November 28, 2011 4:22 PM
To: General discussion for
Jacob, you mentioned in an earlier post you linked against Version.lib.
I did a search on my machine for that and found 13 Version.lib files.
Which one are you referring to?
--
All the data continuously generated in you
I don't know about wixstdba, but the managed ba actually parses (at least) the
param "/log logfile.txt"
Regards,
Nicolas Penin
-Message d'origine-
De : Rob Mensching [mailto:r...@robmensching.com]
Envoyé : lundi 28 novembre 2011 22:07
À : General discussion for Windows Installer XML too
19 matches
Mail list logo
