InstallAware

I'm doing the "Works with Server 2008" self-test with VeriTest to get our product logo certified.

The setup.exe generated by InstallAware (CD/DVD media mode) does not have "Product Name" or "Product Version" in the version information resource, even though the Project Settings clearly have these fields populated.

I'm wondering if I'm doing something wrong with InstallAware.

The initial response from InstallAware support is that the certification documentation must be wrong. To be frank, I've found the certification documentation from Microsoft to be very inconsistent and nearly impossible to follow. However, the "Test Lead" that I'm working with at VeriTest has informed me that we cannot achieve "Works with" logo compliance without those properties set in the setup.exe.

I even tried using a resource hacker to set the properties myself. The properties do appear in Explorer, but this corrupts the install package. (I didn't really expect it to work, or at a minimum it should break the digital signature, but I'm getting desperate here.)

Any guidance or advice would be appreciated.

You emailed us a screenshot - it already contains the file version and file description fields correctly populated. Please ask your Veritest contact to furnish you with solid documentation as we've had all our customers pass certification, but the odd Veritest engineer will always cause trouble, even though our installers are up to spec.

sigh I really wish I knew how to communicate better.

I did not say anything about "file version" or "file description" being populated. Let's put the certification issue aside for a moment.

In InstallAware's Project Properties, I set "Product Name" and "Product Version". Now, Windows executables have a version information resource (see http://msdn.microsoft.com/en-us/library ... S.85).aspx). Two of the strings that can be stored are "ProductName" and "ProductVersion". If you read the MSDN article, and search for those two string names, you'll see that the MSDN documentation states "This string is required" for each of those.

I would expect, and want, InstallAware to generate a setup.exe whose version information resource has the two strings "ProductName" and "ProductVersion" populated based on the "Product Name" and "Product Version" values that I set in the InstallAware project.

Does InstallAware support doing this? If not, may I submit it as a feature request?

Now, back to VeriTest. I will send him another email with your feedback. VeriTest has informed me that the product will not receive the certification that I'm seeking. I have no reason to expect that they will change their mind just because you disagree with their decision. Furthermore, the MSDN documentation states that those two strings are required if a version information resource is added to the executable. If MSDN states that it is required, it certainly makes sense to me that the logo certification would require it.

Jon

I just checked the "Windows Server 2008 Works with Specification.doc" and I can see your argument. That document only states:

"The properties of an executable file (with the extension .exe, .dll, .ocx, .cpl, or other extension) must contain an accurate product name, company name, and file version."

By changing the "Subject" of "Summary Information" in InstallAware, I got the File Description to be an accurate product name. I sent an email to VeriTest to see what they say.

However, the MSDN documentation states that "ProductName" and "ProductVersion" are required to be populated. The amount of code to do that, since InstallAware is already creating a version information resource, is extremely minimal.

I would rather see InstallAware comply with Microsoft's requirements for version information resources and make a customer happy, rather than continue to argue that it isn't necessary.

Candice let me know you were disappointed with the way this thread was handled.

I'd like to let you know that while to you this seems like a very "simple" change; thanks to inconsistencies at Veritest, there are tens of such "simple" changes that surface pretty much each time a revision happens in any one of the logo programs. Not only is it a waste of time to keep making these "simple" changes each time docs are updated, it is unnecessary and wrong in the first place:

InstallAware continues to meet the highest requirements bar, which does not change that frequently, needless to say.

FWIW, we've escalated this case to Microsoft to see what they have to say about it. Based on past statistics, this will turn out to be yet another colossal waste of time on all four parties combined. Not happy with Veritest

Thank you for replying, Michael. And thanks for escalating the issue with Microsoft. It is their tool that is reporting the "failure". So, if in fact this is a moot issue, I'll be more upset with Microsoft than with VeriTest.

Can you address my enhancement request, putting aside VeriTest for a moment?

The version information resource added to setup.exe does not have the "ProductVersion" and "ProductName" strings populated. According to MSDN documentation (see "string name" section of http://msdn.microsoft.com/en-us/library/aa381058.aspx), these strings are required.

I'm requesting an enhancement that the "Product Name" and "Product Version" values that are specified on the "Project Properties" page of the InstallAware project are placed in the corresponding version information resource strings in the generated setup.exe.

Thanks again.

I think you've missed the point of my response to you.

I don't think so. I think your point was that making changes to satisfy VeriTest's changing requirements/specifications/demands is a waste of time and resources.

I agree that chasing someone else's changing requirements is a waste of time. Unfortunately, due to Insurance regulations, we have to do it on a weekly basis.

My point is that if VeriTest didn't even exist, and if Microsoft Certifications didn't exist for software applications or installers, there is still the Microsoft Platform SDK, which states that a VERSIONINFO Resource is required to have two strings populated and InstallAware is not populating those two required strings.

InstallAware is not complying with Microsoft's documented requirements for VERSIONINFO Resources. You can either ignore that, dispute it, or acknowledge it.

If you dispute it, please provide the documentation stating how I can enable this feature. I've searched all available documentation and cannot find this information.

If you acknowledge it, you can either add it to an "enhancement" list, or tell me that InstallAware will never comply with Microsoft's documented requirements.

So far, you've repeatedly ignored it.

I don't think I'm getting across.

Before I get this thread locked, I will make one last effort to get through.

InstallAware customers have received Vista Certified logos MANY times before.

Our contact at Microsoft has informed us that the "Works With" tier is a lower tier than this and should be working.

We are not about to go around creating unnecessary product updates because documentation, Veritest, or anybody else is confused.

We're still waiting for further clarification from Microsoft and will let you know when we hear back. Demanding that we comply with what you think is right or what would be most convenient for you will not produce results that you hope for.

You are definitely getting across. Go ahead and lock the thread. It doesn't look like I'll be using the product anyway.

You continue to ignore the fact that InstallAware does not comply with the Microsoft documentation for VERSIONINFO Resources. This issue has nothing to do with Vista Certified logos.

I'm no longer discussing certification issues. Perhaps I should have started another thread with a different subject, but I don't think that would have mattered.

This isn't a debate about who's right or wrong, but about what InstallAware can realistically do for you - and all our other customers.

Here's the response from Microsoft (emphasis mine):

I am on a thread with Veritest as well, and have responded likewise:

For proper binary information, the Works with Tool is looking at the value of these header Properties:
Company Name
Product Version
File Version

This means that any value for File Name Property would be overlooked by the Works with Tool, and failing this test case.

Is it only Setup.exe that is failing, or are other binaries affected as well?

That said, the Logo Program has just announced that the following two test cases are now Best Practices and optional for achieving Works with Logo:
Did the application binaries have valid file version information?
Were all executables installed by the application signed?

Does that help?

In other words, it repeats my point

Thanks Michael. I'll forward this to VeriTest and we should be able to proceed with our certification.

Maybe, just maybe, InstallAware will someday comply with the MSDN specified requirements. Since InstallAware "continues to meet the highest requirements bar" (emphasis mine).

MichaelNesmith wrote:Here's the response from Microsoft

After this experience, I'm a skeptic of InstallAware. Having said that, VeriTest sent me the EXACT same Microsoft response.

I can't help but laugh at myself at times...

We're following official published documentation from Microsoft's logo site (outside of MSDN), but as you can see, the "extra" requirements come and go very rapidly