MSIOpenPackage on Windows 7 behavior changed? (0x80070645)

[dblock]

On Windows 7 the behavior of MSIOpenPackage seems to have changed. We
use it to run unit tests by creating a database (MSICreateDatabase)
and calling MSIOpenPackage to get a working handle. On Windows 7 it
always returns 0x80070645: This action is only valid for products that
are currently installed.

I tried MSIOpenPackageEx that accepts
MSIOPENPACKAGEFLAGS_IGNOREMACHINESTATE that claims to ignore the
machine state. Same result.

Anyone seen this?

Thanks,
dB.

[Adrian Accinelli]

"dblock" <dbl...@dblock.org> wrote in message
news:8ba80b8b-1c58-4b24...@b18g2000vbl.googlegroups.com...

Can you provide some sample code that reproduces this behaviour?

For me the equivalent of this pseudocode below works fine on Windows 7
x64/x86 and other platforms:

PMSIHANDLE hDB, hProduct;
MsiOpenDatabase( path, MSIDBOPEN_DIRECT, &hDB );
...
wsprintf( szhDB, "#%d", (MSIHANDLE)hDB);
MsiOpenPackage( szhDB, &hProduct);

Sincerely,
Adirian Accinelli

[dblock]

::CoInitialize(NULL);

MSIHANDLE hDB = NULL;

wchar_t * lpszFilename = L"C:\\temp\\MsiOpenPackage.msi";

DWORD dwError = 0;
if (0 != (dwError = ::MsiOpenDatabase(lpszFilename,
MSIDBOPEN_CREATEDIRECT, & hDB)))
{
std::wcerr << L"Error creating: " << lpszFilename << L": 0x" <<
std::hex << HRESULT_FROM_WIN32(dwError);
return dwError;
}
::MsiCloseHandle(hDB);

MSIHANDLE hProduct = NULL;
if (0 != (dwError =::MsiOpenPackage(lpszFilename, & hProduct)))
{
std::wcerr << L"Error opening: " << lpszFilename << L": 0x" <<
std::hex << HRESULT_FROM_WIN32(dwError);
return dwError;
}

::MsiCloseHandle(hProduct);

std::wcout << L"OK";
return 0;

I am trying via the existing handle and not the filename now ...

[Adrian Accinelli]

"dblock" <dbl...@dblock.org> wrote in message

news:4b57f1aa-15a1-410a...@t1g2000vbq.googlegroups.com...

Using the code you provided I receive error 1620 or 0x80070654 -- not
0x80070645 which is what you originally stated. I received this on both
Windows 7 and XP with MSI 3.1. In fact this result actually indicates that
things are working properly because in the code you are effectively
overwriting/creating a new MSI file and then closing it without putting any
tables or summary information. This leads to an invalid MSI file which is
why you get 1620 when you attempt to work with that MSI again.

Now if I use MSIDBOPEN_DIRECT instead of MSIDBOPEN_CREATEDIRECT your code
works.

So either the sample doesn't show your real problem (0x80070645) or maybe
you mistyped the error code originally (switching 45 instead of 54)?

Sincerely,
Adrian Accinelli

[dblock]

Ok. My bad for the repro, I was boiling it down from a big C++
codebase. I didn't see that this was a different error code (looked
very similar). The MSI indeed needs a summary informaiton, once it has
it, I am back to the error I was talking about.

Take a look at
http://svn.vestris.com/filedetails.php?repname=Vestris+SVN&path=%2Fcodeproject%2FMsiOpenPackage%2FMsiOpenPackage%2FMsiOpenPackage.cpp.
On Windows 7, this returns

Error opening: C:\temp\MsiOpenPackage.msi: 0x80070645 This action is

only valid for products that are currently installed.

You can get the full project with Subversion at
svn://svn.vestris.com/codeproject/MsiOpenPackage, so you don't have to
copy-paste stuff.

Thanks,
dB.

[Adrian Accinelli]

"dblock" <dbl...@dblock.org> wrote in message

news:22220563-a2c7-4401...@s17g2000vbs.googlegroups.com...

> Ok. My bad for the repro, I was boiling it down from a big C++
> codebase. I didn't see that this was a different error code (looked
> very similar). The MSI indeed needs a summary informaiton, once it has
> it, I am back to the error I was talking about.
> Take a look at
> http://svn.vestris.com/filedetails.php?repname=Vestris+SVN&path=%2Fcodepro

> ject%2FMsiOpenPackage%2FMsiOpenPackage%2FMsiOpenPackage.cpp. On Windows
> 7, this returns
> Error opening: C:\temp\MsiOpenPackage.msi: 0x80070645 This action is

> only valid for products that are currently installed.

> You can get the full project with Subversion at
> svn://svn.vestris.com/codeproject/MsiOpenPackage, so you don't have to
> copy-paste stuff.
> Thanks,
> dB.

Ok there is a behaviour change in Windows 7 (and I confirmed XP with WI3.1
does not share this new behaviour). In order to use MsiOpenPackage you now
have to have a Property table with a populated ProductCode value in the MSI
file itself. I suppose this is why this particular error is coming up
because the installer can't find a ProductCode value in your MSI and as a
result it bails out at the early product already exists check.

Perhaps a brief community note on the MSDN page is in order?

Sincerely,
Adrian Accinelli

[dblock]

Thank you. This works. I added a comment to MSDN.