I’m generating projects for unix and windows with cmake. For win we use certain version of vs build tools, which are a bit outdated already. As a result each time I launch generated project, I get project upgrade prompt, which is quite useless.
I’ve found that thread on how to disable it via certain oneliner:
<VCProjectUpgraderObjectName>NoUpgrade</VCProjectUpgraderObjectName>
The question is how do I insert it into project during cmage gen process.
Related
We made some changes to the installation and updating process of our Windows app recently, and some users are now complaining that Windows sometimes automatically deletes the main application .exe file.
It usually occurs after users update app using built-in web update feature. The feature is implemented using .msi built in Advanced Installer tool.
We are struggling to figure out what is causing this, and haven't found a way to consistently reproduce the issue (though we've seen it happen as well).
Here's what changed with our installation and web updating process:
The main installer for our application is now a standard .msi, which becomes a part of the Windows installation system and is natively manageable by Group Policy and other system features, such as rollback or versions. In previous versions that did not have this problem, our installer was a .exe built with the SetupBuilder tool.
We introduced the redesigned web updater feature inside the app (to update to new versions within the app). It uses the same .msi as the main deliverable as for installation. .msi is downloaded from our server in a form of .exe which is then extracts MSI and starts it. MSI then updates file in our installation. These .exe and .msi is built with Advanced Installer tool which provides such a web update feature to developers. In previous versions that did not have this problem, our web update feature was developed with SetupBuilder tool which provided a custom web update files - .exe web updater that downloads a number of web update files containing patch to our app.
The goal of a transition to the standard .msi installer was to make it easy for our clients to deploy the app in organizations - say, mass deploy using group policies and other similar tools.
Has anyone else experienced a problem like this? Any ideas on how to troubleshoot and try to reproduce?
Theory: Before doing anything else: The first thing I would ask the people who report the problem is if they have re-packaged your older, legacy (non-MSI) setup to be their own MSI file? This can cause a well-known upgrade problem along the lines of what you explain (file missing). Please check first. Tell them to uninstall the existing version and then install the new one - that is the simplest way. Not always enough (some obscure problems possible).
Mismatched component GUIDs could cause missing files after upgrade, as could file version downgrade scenarios and various other technicalities. You could try to install to a new default location on disk to avoid these problems. The reason this can work is very technical and hard to explain tersely. Essentially you de-couple yourself from "the sins of the past". It is generally enough to change the name of the file in question: for example MyApp.exe to MyAppNew.exe or maybe add the major version: MyApp5.exe, but maybe try the folder change first ProgramFiles\MyCompany\MyApp => ProgramFiles\MyCompany\MyApp5.
How do you configure your upgrade? View "Upgrades", what is selected: "Uninstall old version first and then install new version" or "Install new version first and then uninstall old version".
Blog Entry:: Why Windows Installer removes files during a major upgrade if they go backwards in version numbers (might be of help).
Deployment Debugging: For open ended debugging of MSI and deployment problems in general one obviously needs to gather intel and that means logging and system inspection.
Logging: First try to get a proper log file for the systems where this problem occurs. In Advanced Installer you can tick the "Enable verbose logging" in the Install Parameters view to enable verbose logging for all package installations. This adds the MsiLogging property to the compiled MSI and every installation of the MSI will cause a MSI log file with a random name to be created in the TMP folder. View the folder, sort by date and the file should be at the top. Suggest you do this and then tell the users to send you the log files when relevant. Maybe you have this setting enabled already?
Further Logging: There are many ways to enable logging, and you can find a description here: Enable installation logs for MSI installer without any command line arguments. The MsiLogging property is just one possibility.
To log a single MSI setup: http://www.installsite.org/pages/en/msifaq/a/1022.htm.
To enable global logging for all MSI operations on the machine: Please see this FAQ-entry from installsite.org, section "Globally for all setups on a machine" - for the exact procedure.
How to interpret an MSI Log File.
I am trying to run the Q# Teleportation sample. I cloned from the official Microsoft GitHub Repository, restored all dependencies, I have the Q# Development SDK installed also. The problem is when i run it the first time it worked now i tried running it again and i get this error.
TeleportClassicalMessage' does not exist in the current context. I run it for the last time and it worked even with the Error. I have by the way set up TeleportationSampleas my startup project.Is there any reason for this behaviour?. I am new to Q#
Even with the red Squiggly the Application run after another try.
I solved this by deleted the bin and obj directories then run again.
my experience: Quantum Program The name 'BellTest' does not exist in the current context
From my experience (playing with slightly modified sample BellTest code), Q#-generated classes are properly referenced in C# only after you rebuild project (meaning dotnet build). So if you make some changes in names that are visible on the C# side, try building it and reference issues should go away.
This was tested using VSCode on Windows 10 x64, .NET Core v 2.1.103
Over the years our InstallShield code has grown un-manageable and messy. We're about to design an InstallShield 2015 installation from scratch for a new major release, and I was wondering if there's any way to automatically capture a set of system changes to use as a cleaner starting point for developing a new install package. Ideally, I would like to turn on some capturing software, install the oldest release from which we support an upgrade, install the latest service packs, and then apply the manual changes that will get the new release running on the system. Then I would turn off the capturing software, and it would provide an InstallShield project pre-loaded with all the files and registry entries (GAC changes, .NET assemblies, etc) that were created as part of that install. Then I could add steps to delete those that we no longer needed and do some other clean-up and refinements. Does such a thing exist?
Yes, this is called a repackager most often, in the enterprise world where sys admin and packagers prepare applications for deployment on the company machines.
Flexera has one that can create a project for InstallShield, but it is sold together with their AdminStudio solution, which is not cheap.
We (at Caphyon) have a repackager included in Advanced Installer (the architect edition) which also requires you purchase license. And of course the generated project will be compatible only with Advanced Installer, where you can configure your installers as you wish.
I think there is also a free repackager, AppDeploy from Dell, but I never used it, so I don't know how accurate it is and if you can use the results created into InstallShield or if it generates directly an MSI.
If you started looking more careful you will probably find other repackager tools, but you should know that building such a tool is not an easy task so choose carefully. Also probably only the one from AdminStudio will be able to generate a project that can be read by InstallShield.
If you already have the source projects from the older editions I would personally not try using a repackager. Instead I would go for cleaning up all the configurations which you do not understand and re-build them from scratch.
A repackager as good as it can be still has some problems. It can capture incomplete data, for example if you have a custom action that runs different code based on the OS where the installer is running the repackager will capture only its effects on the OS where you run it. On another one might run differently and have another output.
Also if your installer has prerequisites and you run the repackager on a machine where those prerequisites are installed then the repackager will not capture anything related to this, so by accident you can forget to include required prerequisites in the new package.
There is also the things like meta-information which few repackagers can detect. For example files associations which are actually a set of file and registry entries connected together or environment variables, scheduled tasks, etc...
Most repackagers capture all this data and simply show it to you as configuration files and registry entries, instead of creating the correct entities in your projects, i.e. files associations, environment variables or scheduled tasks in their correspondent views.
I'm trying to build a publish script that doesn't use VS2010 -- I want it to be automated and in powershell (may use Psake soon). The biggest issue that I run into is that a project that will build and publish fine in VS2010 will either not build or not publish via the msbuild command. The closest I can get is (anonymized code):
msbuild /p:OutDir=c:\temp\publish\staging\myProj\myProj_1481\;Configuration=Debug;UseWPP_CopyWebApplication=True;PipelineDependsOnBuild=False C:\TEMP\export\myProj\1481\src\myProj.com\myProj.csproj
That one is failing for a Could not find file error in one of the DLLs. Naturally it publishes fine from VS2010. Is there some sort of recursion that I need to do? I'm burning up quite a bit of time on this one particular portion of my script -- the one part I have the least control over.
Requirements:
if the proj will build in VS2010 I shouldn't need to modify the csproj file -- I don't want to hand this script off to someone else and have them stick in "fix your csproj" land for hours per project
have to be able to script it entirely at the command line
hopefully no additional installs needed
Related:
Trying to Build and Publish Asp.net website from command line using aspnet_compiler (old)
_CopyWebApplication with web.config transformations (didn't fix my issue)
I have a solution that I would like to run each day, but simultaneously continue development on it. While it is running, when I attempt to build a new version I receive the error that "Unable to copy file "obj\x86\Debug\Solution.exe" to "bin\Debug\Solution.exe". The process cannot access the file . . . ". This is perfectly understandable: the currently running version has a lock on the .exe, so a new one cannot be created.
My question is this: what is the best practice to "release" the current version to run each day, while keeping a separate "debug" version available for development? My current approach is to create a separate copy of the project, but that is very tedious. Is there a better way?
Thank you,
Ben.
Build a Release Version, run it from folder. (Set Solution Configuration to Release)
Develop and debug in debug mode.
Assuming this is a Winforms or WPF app you can right click on your project, click on Properties and go to Publish tab. From there you can publish your app to a UNC path, install from there and run it while continuing development from within the Visual Studio IDE.
Edit: Additional advantage of this approach is that when you have a new version you will be able to publish to the same location and the next time you start your app it will be automatically updated.
Are you using any source control system? It's not clear if your problem is simply the mechanics of making a build, or how to keep a copy of your source that corresponds to each build. If the answer is b, then a source control system is designed to solve this problem.
You would make a build each day and publish/release the binaries, while at the same time checking in your source code. That way you have a "copy" of your source code that corresponds to each released build, while still allowing you to continue active development.
I would use a post-build script to simply copy the resulting EXE to a new location. You can run it from there easy enough. You can even execute it in the script if you don't like double-clicking ;)