So it seems as a pretty easy Task, I created a VSIX which I uploaded a few days ago. Some days later I fixed some issues and now I want to update the extension on the marketplace.
I went ahead and took a look at the MSDN which states the following:
Unsigned all user extensions do not get updated automatically. You should always sign your extensions.
So therefor I went on an tried to sign my VSIX as explained here. Which tells me to do the following:
Search for VSIXSignTool from VisualStudioExtensibility and install the NuGet package.
After downloading the package, I searched for the given location which should be in your project's local packages location. Which makes me wonder, cause I do not have any local packages folder for this project. Furthermore I should sign my extension with the following command:
VSIXSignTool.exe sign /f <certfile> /p <password> <VSIXfile>
Which makes me wonder, what kind of certificate that should be, what should be the password be, a new password?
Anyway, lets assume I somehow mange to do that, how would I 'update' the extension than? Just upload it again as a new package with a new VSIX-Id?
To sum it up, this are my questions:
How/Where do I download the VSIXSignTool
What parameters do I need to pass into the VSIXSignTool command provided above
How do you really update the extension on the marketplace and do I need a new VSIX Id
I suggest first try to update your extension without signing. Just increase the version number and on the marketplace site click Manage - ... (More Actions) - Edit - Upload Extension/Edit package.
VSIXSignTool requires a code signing certificate that needs to be purchased.
Related
We have several hundred SSIS packages in a Visual Studio Integration Services project. When this was originally set up it was configured to encrypt sensitive data in the packages with the user key. This caused some issues for us when the project file was checked out and we had conflicts because, of course, our different developer user keys were different.
We just attempted to change to sensitive data with password. To do that we had to update the project property and then we had to do it for every package manually (I tried looping using dtutil.exe but for some reason it did not work). To build my project I had to open every single package, change the password, and then build the project. After a few hours of this and getting every package updated and saved I was able to build and deploy my packages.
After that I did a commit/push to source control (Azure Git) and when my co-worker did a pull and opened the project they are now unable to build with the same error. If he puts the password in and checks everything in and I pull it back down, I get the error again.
The package and project passwords match, I can build, but when it's pulled down we get the error.
The error is:
"Project consistency check failed. The following inconsistencies were detected:
[package Name] has a different password than the project"
I was able to get around this issue but I was not able to figure out exactly what is occurring. I basically changed my protection level to DontSaveSensitive and made sure all of my passwords and sensitive information were parameterized and passed in using SSIS environment variables.
So after making sure all sensitive data was not saved in the packages I changed the project protection level and the protection level of every package. I changed the packages using this code:
for %f IN (*.dtsx) DO dtutil.exe /file %f /encrypt file;%f;0 /quiet
This changed the setting for the packages but I still received the error when building. I had to open each package, change the protection level property to any other value then back to DontSaveSensitive and then build. Once I did that the items fell out of the error message. After doing that manually for 650+ packages I was able to build. The most important resolution was that once I did a push and my co-worker pulled the changes down, they did not have to edit each package. When I was using encrypt sensitive with password we could not stop it from requiring a change and build on every package.
This is still a bit of a mystery, why dtutil.exe would not just change them without needing to re-build is very frustrating. But this work around ultimately got us past the problem and parameterizing was probably the best practice anyway.
I just had the same issue, my problem was that I was missing to introduce the password in the properties of every package (not only in the project), after doing that I have been able to rebuild the project.
I need some help regarding Install4J and the auto online update function.
We have a JRE bundled Install4J installer which works fine. We use the auto online update functionality which works fine, too. All this functionality in integrated to a continuous integration process in TeamCity.
Unfortunately the update installation setup file has a size of around 100MB which is inconvenient to download if we only want to apply a patch or a minor update.
As far as I have understood from other similar questions and the Install4J documentation the right way to deal with that is using a second project file with another application ID and setting up an Add-On-Installer which only contains relevant files and points to the full installer application ID.
To enable the auto online update functionality I have to upload the update.xml file from the Add-On installer, am I right?
By the way, does the Add-on online auto update procedure automatically detect the locally installed version correctly?
But in that case we have to adapt the add-on installer each and every time we are deploying a new patch or minor feature which is difficult to implement in the CI process.
Is there a way to configure an Install4J installer so that it automatically gets the information online which elements have to be updated so that the download size is as small as possible and we could just use one default add-on installer which contains all sources beside the JRE bundle?
Something like an online incremental update procedure which is managed internally by Install4J?
Thank you.
You should never use the add-on installer for updating, because it cannot change the version number.
In order to get smaller update installers, you create a second project where the distribution tree only contains the changed files - or at least does not contain some large files that did not change. To do that, you simply copy the original installer and delete the files in the distribution tree that you do not need to update.
Then you build two sets of installers, those for a new installation and those for the update.
Some time ago, we distributed a toolbox to our users via the MATLAB App Packager, to make it easier to provide future updates, without users having to handle search paths. Now, we wish to distribute an updated version. Usually, re-packaging the toolbox should make a new .mlappinstall file, which asks the user to upgrade. Instead, MATLAB now considers the new version of the app as a unique new app, and installs it again rather than upgrading. Thus, the user will then have the app twice in the Apps pane, one in an outdated version, and one in the new version.
We have been unable to find an explanation for this in the MATLAB documentation nor online. When we install the updated app (so that both versions are present in the Apps pane), further changing it will upgrade it as expected, so unfortunately, we cannot provide a minimal working example, as we cannot reproduce the issue.
The question is this: How does MATLAB establish app uniqueness? The app name and author fields are identical to the original values, and the version number is incremented, so why might MATLAB not recognize that the app is already installed?
When you had that discontinuity, were you re-packaging using the original .prj file by clicking on it in the file browser in Matlab, or did you run "Package App" again and fill in the same properties?
I think the thing that determines the unique identity of the app is a GUID that is generated behind the scenes by the "Package App" wizard. If you open an existing .prj in the Matlab GUI, it re-uses that GUID. If you run "Package App" again you'll get a fresh GUID regardless of what you put in for the various developer-visible app properties.
You can dig around in the .prj and .mlappinstall files to see this yourself. (I couldn't find it documented anywhere either; I just poked around the files and did some trial and error.) The .prj is just XML, and the .mlappinstall file is a zip file with an "Open Packaging Convention" layout. In the .prj, there's a param.guid element containing the GUID. In the .mlappinstall, its in metadata/appProperties.xml in a GUID element.
If you end up with the same problem again, make sure to re-package using the existing .prj file. Or if you don't have it, once you create your new .prj file, dig the old GUID out of the metadata/appProperties.xml from the old .mlappinstall file and copy it in to your new .prj file and I think it'll behave as the "same" app. This will even let you change the name and contact info for your app, and it'll still install on top of older versions.
When I try and apply a minor upgrade to my application, I launch the installer and (depending upon the combination of settings I try) I get either a:
repair/remove dialog
prompt for the install directory
I don't believe I should get either of these prompts. I'm mostly expecting the installer to automatically apply the upgrade and not prompt for anything. I think I'm doing everything correctly in the Visual Studio setup project:
upgraded the version from 1.0.0 to 1.1.0
left the product code the same
updated the package code
left the upgrade code the same
launch the installer with the parameters REINSTALLMODE=vomus REINSTALL=ALL
I've tried just about every combination of codes/flags and techniques, but cannot seem to get the update applied.
Any ideas of what else I can try?
To get it to work I:
upgraded the version from 1.0.0 to 1.1.0
left the product code the same (said No when prompted by Visual Studio)
updated the package code (Visual Studio did this automatically)
did not change the upgrade code
launch the installer with the parameters REINSTALLMODE=vomus REINSTALL=ALL
Just as I had indicated in my question, and it seems to be working. I can successfully apply an upgrade. However, when I run the installer I am still prompted with a repair/remove option. But, that's a different question I guess.
Just first things first: Are you sure you haven't re-used the package GUID in both MSI files, or at some point during deployment work and testing?
Try rebuilding both MSI files with new GUIDs to "de-couple" them from any existing cached versions and then try test installing again. Change both the package code and product code. Better yet: test these new versions on a clean virtual machine to ensure a proper test environment unaffected by past sins. Your developer system could have gremlins in its Windows installer database due to package guid clashes. If this is the case package installation becomes total XFiles - the strangest things can happen.
More details:
If the package GUID is the same for two MSI files, Windows Installer will treat them as the same file by definition - no matter what they contain. This can cause all kinds of strange problems that are hard to clean up and debug. Note that this can happen even if you just forgot to update it once since installation of an MSI will cause it to be cached on the system in the C:\Windows\Installer folder (this folder is hidden and protected). This cached copy will be re-used if an MSI file with the same GUID is launched (at least this was the case for earlier versions of Windows Installer - there could be fixes for this now).
If you are using Installshield you should enable the "always generate packaging GUID" feature to ensure this never happens. Package GUID should always change for every single build - there is no reason whatsoever to keep it hard coded. I believe WIX takes care of generating the package GUID automagically, unless you specifically override it.
A new version of our product (a software package) has been released recently. To expand functionality, we developed a plugin afterwards. Now we would like to deploy these files (two new files and an updated version of an existing file) as hotfix (or update) with MSI patch (msp). I downloaded a blank PCP file from MSDN website and made some changes in it. The changes involve the following tables:
ImageFamilies
PatchMetadata
PatchSequence
Properties
TargetImages
UpgradedImages
All the other tables remain blank.
Then, I managed to create an msp file with this PCP file based on two versions of the admin image of the software package, both of which were built from Visual Studio setup project (VS 2010). The difference between these two msi packages are that I replaced a file and added two new files in, but nothing else. I didn't change the product code (GUID), the upgrade code (GUID), nor the version number.
Then I was trying to install this msp file on top of the released version.
The first screen appearing is asking to Repair or Remove the product. This is not what we want. We want the installer is like a fresh installation, including showing the licence agreement. How do I define the UI for MSI patch?
During the installation of the patch, I got an error message as below, then the installation failed:
Error 1001. Exception occurred while initializing the installation: System.IO.FileNotFoundException: Could not load file or assembly 'file:///C:\WINDOWS\system32\Files\BPS\TestApp' or one of its dependencies. This system cannot find the file specified.
BPS is the folder where we install our product in [ProgramFilesFolder]. I wondered why MSI was trying to search in "C:\Windows\system32" for files installed in [ProgramFilesFolder]. In addition, the changed files in the hotfix are located in somewhere else ([CommonAppDataFolder]) instead of in this "BPS" folder.
Can anyone help me with these problems? If any more information is needed to identify the issues, please let me know. Any thoughts, advices, suggestions would be very much appreciated.
Dan
The first screen appearing is asking
to Repair or Remove the product. This
is not what we want.
In the upgrade package increase the Product Version. This way you will use a minor upgrade instead of a small update.
You can also try using the MSIEXEC command line to apply the patch:
http://msdn.microsoft.com/en-us/library/aa367574(VS.85).aspx
http://msdn.microsoft.com/en-us/library/aa367575(VS.85).aspx
During the installation of the patch,
I got an error message as below, then
the installation failed
Is there something in your installer using that file? Perhaps a custom action? Try looking in the log to see what action tries to access that file.