Error 1316 Help!
I have an issue with a package. Essentially, I take the pre-existing .wsi and rename it to a new version.
Example:
PACKAGENAME QA v100.msi becomes PACKAGENAME QA v110.msi
The package code / product code remains the same. The ProductVersion is changed from 1.0.0 to 1.1.0.
In this particular installation, no files have changed, only registry settings.
This has so far worked (Although not my preferred method of packaging) but now I'm receiving an error.
"Error 1316. A network error occured while attempting to read from the file: C:\temp\Source\PACKAGENAME QA v110\PACKAGENAME QA v100.msi"
Notice the referenced path name is correct however the name of the .msi references the previous version (which is installed on the machine).
I've been doing this for a while now with some minimal issues that I've been able to fix. This has been driving me nuts all day. I've googled this error and found some explanations but the only solution was to install this program. That's great if you're an end user having the issue but I'm the packager and I don't want to create the issue.
Basically, the first package is installed "PACKAGENAME QA v100.msi" then I install the new package "PACKAGENAME QA v100.msi" with a /REINSTALL=ALL REINSTALLMODE=vamus
I'm sure I missed something simple here but I can't seem to put my finger on it.
Any suggestions / advice would be greatly appreciated.
Thanks
Example:
PACKAGENAME QA v100.msi becomes PACKAGENAME QA v110.msi
The package code / product code remains the same. The ProductVersion is changed from 1.0.0 to 1.1.0.
In this particular installation, no files have changed, only registry settings.
This has so far worked (Although not my preferred method of packaging) but now I'm receiving an error.
"Error 1316. A network error occured while attempting to read from the file: C:\temp\Source\PACKAGENAME QA v110\PACKAGENAME QA v100.msi"
Notice the referenced path name is correct however the name of the .msi references the previous version (which is installed on the machine).
I've been doing this for a while now with some minimal issues that I've been able to fix. This has been driving me nuts all day. I've googled this error and found some explanations but the only solution was to install this program. That's great if you're an end user having the issue but I'm the packager and I don't want to create the issue.
Basically, the first package is installed "PACKAGENAME QA v100.msi" then I install the new package "PACKAGENAME QA v100.msi" with a /REINSTALL=ALL REINSTALLMODE=vamus
I'm sure I missed something simple here but I can't seem to put my finger on it.
Any suggestions / advice would be greatly appreciated.
Thanks
0 Comments
[ + ] Show comments
Answers (8)
Please log in to answer
Posted by:
pjgeutjens
13 years ago
The package code / product code remains the same. The ProductVersion is changed from 1.0.0 to 1.1.0.
I think you're mixing up major and minor upgrades there. Have a look at this site for an overview of what you can/should change for which scenario. Note that you should ALWAYS change at least the package code when making ANY changes to an MSI. If you don't the data Windows Installer stores in the registry under HKCR\Installer will most likely mess up your install, as I think is the case here (the PackageName value comes to mind ;-) ).
Since you changed the name of the MSI, you'll want to do a major upgrade, which means changing PackageCode, ProductCode and ProductVersion. What stays the same is the UpgradeCode, and this will be the driving mechanism in replacing the old version, through an entry in the Upgrade table of your new MSI.
PJ
Posted by:
Secondlaw
13 years ago
PJ,
Thanks for the link. The issue here is that for each product, I'm told to keep the package code the same. I understand that it should always be changed! This is my companies way of doing it. I tried to tell them we should change it. Needless to say, I changed it prior to my post just to see if that would help. It doesn't, I still get the same error.
Any other suggestions?
Thanks again
Thanks for the link. The issue here is that for each product, I'm told to keep the package code the same. I understand that it should always be changed! This is my companies way of doing it. I tried to tell them we should change it. Needless to say, I changed it prior to my post just to see if that would help. It doesn't, I still get the same error.
Any other suggestions?
Thanks again
Posted by:
Secondlaw
13 years ago
Ok... I changed the package name so I will have to conform with this. :(
Thanks, PJ.
Thanks, PJ.
Posted by:
pjgeutjens
13 years ago
I suppose you could try changing the data stored in the registry (HKCR\Installer) for the product, changing the PackageName value before you install the newly named msi.
Other than that, it wasn't me who decided that an upgrade when changing the msi filename, has to be a major, it was Microsoft ;-)
I understand your situation though, in the end it's your client paying the bills.
PJ
Other than that, it wasn't me who decided that an upgrade when changing the msi filename, has to be a major, it was Microsoft ;-)
I understand your situation though, in the end it's your client paying the bills.
PJ
Posted by:
kardock
13 years ago
ORIGINAL: Secondlaw
... I'm told to keep the package code the same. I understand that it should always be changed! This is my companies way of doing it. ...
it's part of your job to explain to your company what they do wrong and the implications of it.
when my boss tells me "this is how you have to do this" i told him that i'm the packager so i'm the one who decides how i package.
what the company can tell me is the restrictions and standards i need to follow, not how to package.
Posted by:
Secondlaw
13 years ago
What do you tell your boss when he says, "My way or the highway". I'm not saying I don't agree with you but you know... I can only make the suggestions and explain why everyone else seems to do it the way I suggested rather than the way they've been doing it.
Here is an issue I've run into today. I've always added ODBC settings via the registry. They want me to use the ODBC gui/table to insert these entries. My argument was that if the drivers did not exist than the .MSI would fail. Can anyone think of anything else because this didn't seem to be a good enough argument.
Here is an issue I've run into today. I've always added ODBC settings via the registry. They want me to use the ODBC gui/table to insert these entries. My argument was that if the drivers did not exist than the .MSI would fail. Can anyone think of anything else because this didn't seem to be a good enough argument.
Posted by:
kardock
13 years ago
every time i explain to my boss the implication of doing it his way, he would agree with me.
you need to present your stuff so that he will understand your arguments.
if some day my boss tells me "my way or the highway" there will be a packager position opened at my current work. there are many packager positions opened in my area.
edit: i forgot to add that, of course, if my boss has valid arguments against mine, it's not the same. if my boss say go that way with no reason, i fight him and i usually win.
you need to present your stuff so that he will understand your arguments.
if some day my boss tells me "my way or the highway" there will be a packager position opened at my current work. there are many packager positions opened in my area.
edit: i forgot to add that, of course, if my boss has valid arguments against mine, it's not the same. if my boss say go that way with no reason, i fight him and i usually win.
Posted by:
anonymous_9363
13 years ago
this didn't seem to be a good enough argument.PMSL...Priceless. The guy *wants* failing MSIs, so deliver them. Make sure, though, that you add a note to that effect in the 'Summary Information' stream's "Comment" field: you don't want your name associated with junk. It sounds like he's too stupid to check there for anything.
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.