Say clients have v1.0.0.0 of my VSTO addin installed and I want to deploy v1.0.0.1.
If I deploy to a new folder and copy to my update location (only v1.0.0.1 will be in the Application Files folder), will automatic updates still work or do I need to have the old version in the Application Files folder too?
I would say it will work. the setup.exe located under the installation root points to the latest version
Related
When I install my Java application on Windows using Install4J 9.0.5, I'll find a .install4j\user directory inside my installation directory. It contains several jar files and some other files used by the installer.
Do I still need this directory when the installation is finished? Maybe for uninstalling? And is there a built-in way for Install4J to delete this directory if it is not needed anymore?
The .install4j directory contains the runtime for the generated launchers and for installer applications like the uninstaller.
You can only delete it if you only have external installers, no installer applications and if you do not use the install4j API from your code.
I have an application written in Visual Studio 2013, and I'm using a Setup and Deployment Project to distribute it. All of the bullet points in Akash Kava's answer to this question are set:
Installing a new version of a deployment project over old version
i.e "DetectNewerInstall" is set to true, "RemovePreviousVersion" is set to true, etc. I'm also changing the ProductCode and allowing Visual Studio to create a new GUID, but the UpgradeCode is the same. I am also incrementing the version numbers of the C# projects that are added to the Setup Project as Primary Output.
So when a user runs the setup on a machine that already has my software installed, it performs an upgrade. When this happens, all of the content that I wrote upgrades just fine. However, there are some NuGet references (SignalR, Owin, Netwonsoft, etc.) that do not upgrade. Even though the packages were updated in the project and manifest, the installer won't replace the old versions of the NuGet .dlls with the new ones. When I do a new install and examine the .dlls in the Program Files, I can see that the NuGet .dlls are the new version, so I know that the correct versions are being bundled with the Setup Project properly. It just appears that they are not being overwritten if they already exist. And this only happens with the NuGet references; the .dlls and .exes that I wrote upgrade properly.
Is there any way to force the Setup Project to always replace the NuGet .dlls?
However, there are some NuGet references (SignalR, Owin, Netwonsoft,
etc.) that do not upgrade. Even though the packages were updated in
the project and manifest, the installer won't replace the old versions
of the NuGet .dlls
NuGet has nothing to do with deployment and it is supposed to download packages only when you build your project OR you download from console.
Setup/Installer should automatically detect the dependencies based on PrimaryOutput but if some of dlls are not referenced in project and are required for deployment then you should add them to installer project manually.
On creating new installer make sure to build all projects so that installer project can update the dlls to new version if you have changed it in application project therefore no action required to deploy new version of assemblies considering you have already configured installer to remove previous version on installing new version.
We run JBoss 6 in standalone mode. We do have a folder (content.war/) in deployments that contains a symlink to a different folder (let's call it docs). Symlinking is enabled in jboss-web.xml with <symbolic-linking-enabled>true</symbolic-linking-enabled>. Our scenario is to use this to serve static files via this app context.
We do deploy the folder using touch content.war.dodeploy. It all works fine when the docs folder contains just few files. When the docs folder points to actual folder that has around 30GB the deployment seems to be stuck (the folder is not deployed and no other deployment works afterwards).
I believe that JBoss tries to somehow traverse or scan the whole folder. Is it possible to somehow disable this behaviour?
One workaround seems to do the trick. I can deploy an empty exploded war folder and once it is deployed I create the symlink to the huge folder.
Disadvantage: When JBoss is restarted it gets stuck again. I'd need to remove the link and create it again after deployment.
Another option is to use welcome-content that JBoss uses to serve static content. I can remove the original welcome-content folder and create a symlink to my folder instead.
ln ‐sv /home/mypath/my-static-content ${JBOSS_HOME}/welcome‐content
Disadvantage: This doesn't allow you to use any symlinks inside your folder or subfolders.
I did a build publish to a mvc applications and See that packages.config is also deployed even though i did select "Only files required to run this application" in the properties. Can i safely remove this nuget package list file using wpp targets when deploying ?
Yes you can remove it from the deployed application.
It is used by NuGet to keep a record of what NuGet packages are installed in a particular project.
By default, the build process copies all files from source to the destination directory. To exclude the file, right click the file, select properties and for Build Action choose 'None'.
I have an exploded directory that I am editing in eclipse (created via setting location to directory location when creating New Project, deployed directory already existed). When I deploy this directory from the command line, it does not seem to save it locally (anywhere within glassfish\domain_
If I create a Java EE application in eclipse from scratch and deploy it from Eclipse Run -> on server, it copies it to glassfish\domains\domain1\eclipseapps
Is there a way to have GlassFish save deployed directories locally without using the GlassFish plugin magic?
Short Answer: No.
The whole point of directory deployment is speed and development convenience.
You tell GlassFish to not copy any files at all but to, instead, use the files already laid out on disk.
If you want to run from a copy of your app then just deploy the archive (war/rar/ear/jar) file.