This question already has answers here:
HowTo create InstallShield MSI with no files needed locally?
(4 answers)
Closed 7 years ago.
I have created a project in Visual Studio Ultimate 2012 and I have activated Installshield so that I can create a setup-file for my project. The deal is that InstallShield doesn't create one big setup-file, but rather one folder which contains a setup-file I can run to install the project. If I take the setup-file out of the folder, the setup will fail. Do anyone know what I am doing wrong? I feel like the whole purpose of creating a setup-file is to only have one exe-file, not to be forced to go through a folder to find a setup-file.
Added an image of my folder:
Within Visual Studio click Build from the menu bar, then click configuration manager. Within the Configuration Manager dialog, set the Configuration to SingleImage and then rebuild the project.
There are a variety of scenarios that call for different build configurations. A single self extracting EXE is not always desired.
However, if that is what you desire, build the Single Image configuration instead.
Personally, if you don't have a reason to have a Setup.exe ( setup prereqs, multiple instances, minor upgrades and so on ) then I'd just build it as a single MSI.
I have been having this same issue but all the solutions are either based on LE or pre 2013 versions.
So, since the SingleImage is not available in InstallShield Premier 2013 do the following:
In the Release Wizard select Media Type: Web
Web Type: One Executable
This should generate a unique self-contained exe file
Related
I have a small game that I created, using c# on visual studio. How can I make one file out of it so people can download it and play on their own computers? (assuming they don't use coding programs (like Visual Studio) i.e. regular people)
Step 1: Publish in Visual Studio (right click project file and click publish). This will package your project and its dependencies into a smaller number of files. There is even an option to create a single file, which may be all you need. If you need an installer, the ClickOnce publish option works great for creating installers.
Step 2: Some versions of .NET do not support ClickOnce, and depending on what your needs are you may not want to create a ClickOnce installer. In that case you will have to create an installer yourself. I recommend Inno Setup for creating installers. There are plenty of tutorials on how to use it. Brackeys has a pretty good tutorial on Youtube for Unity projects.
I am trying to run multiple apps with the same code, the only differences are application names, icons and the splashscreen.
I am already 100 % sure that my approach must be complete crap, but here is my approach:
I copied the excisting project specific configuring files, changed all file names to the new project, replaced references inside these files and imported this project back to the solution, because creating a complete new product within the solutions ignores all yet created files so I wanted to save some time. Now have 1 solution (I thought of this as the product) and 1 projekt for each customer, all targets sharing all code, except the project configs with the ids, names and icons etc..
But when I try to build any of the project I get these errors
Error occurred while restoring NuGet packages:
The process cannot access the file
'C:\...\project.lock.json'
because it is being used by another process.
Or the assembly is used by another application.
So, this can't be the right way to do what I want to do by Visual Studio, I'm looking for the right way to handle 1 base-product but many customer-specific-apps with Visual Studio 2015.
Sadly I couldn't find any tutorial for that yet.
Maybe I'm searching with the wrong description or naming, I thought of projects as targets in Xcode.
A link to a proper tutorial would already do the job for me.
Thanks!
According to your description, I think what you want is building multiple branded apps from a single Visual Studio solution. If so, here is a nice article: Multi-Branded Apps in Visual Studio (Windows 10 UWP) you can refer to.
The key point here is using separate build configurations for each app and then using Pre-build commands to create the app package.
For more info, please see Understanding Build Configurations and Specifying Custom Build Events in Visual Studio.
I create a new custom project type using a VSPackage project inheriting of MPF library (http://mpfproj11.codeplex.com/). As a result I obtain a .vsix but I need add this project type using a .msi. I'm using the Visual Studio 2010 Setup projet for it. In my setup project I add the content of the VS Package in the same directory where the .vsix put then, but I think Ineed to put in the registre the new type of project because when I use the setup , the project template does not come out in Visual Studio and when I give double click the file with extension of the type of new project and does not recognize it. When I look the registry after install the vsix, this was one of the things that I found diferent. I add this entries in my setup project but It's not working yet.I'm missing something else?
In the projecttemplatedir is the directory where I put the .dll of the project type, the vsixmifest and pkgdef. The project template is in [User]\Documents\Visual Studio 2013\Templates\ProjectTemplates\[Name of new Project Type]\[projecttemplate.zip]
Best Regards
PS: The project type is for VS 2013 but I'm using the VS 2010 Setup project ;)
OK, so first the "don't"s of doing this:
In general, if you are installing via MSI you shouldn't be doing anything user-specific -- no writing in HKEY_CURRENT_USER, nor writing within their Documents folder, LocalAppData, or Visual Studio folders, etc. If you see yourself writing files or registry keys in either of those places, that should be your hint that there's a better way to do what you're trying to do. For what you've shown so far, this raises more than a few red flags for me.
Second, don't ever go writing keys into 12.0_Config. That part of the hive is nothing more than a cache that's built up from other parts of the registry and on-disk .pkgdef files from extensions. It's rebuilt in any number of senarios, including installing new extensions. Any writes there you should presume will get blown away at any time. If you need to write things there you should either (a) write in HKEY_LOCAL_MACHINE\Software\Microsoft\VisualStudio\[version] and run devenv /setup or (2) [preferred] put your keys in a .pkgdef inside your extension which gets merged into 12.0_Config for you automatically.
Now the dos:
You said you already had a .vsix produced by the SDK: you can put project templates in there. You can then register those templates in the .vsixmanifest and those will pull in. That's far easier than mucking around with files in Documents -- that's the user's directory...don't go playing with that.
Once you have a .vsix that does most of what you need, you should simply take the files within that and install the files in a folder within C:\Program Files [(x86)]\Microsoft Visual Studio 12.0\Common7\IDE\Extensions. Even better, you might just want to WiX toolset to build your installer, since it has built-in support for installing extensions. It also has built-in support for invoking the "/setup" process if that's what you need to do as well. Visual Studio Setup projects are no longer supported in newer versions of Visual Studio, so you're better off starting with a technology that isn't already obsolete. WiX is even what we use at Microsoft to do the setup work for Visual Studio itself, so it's definitely up to the task.
Last point: almost everything when it comes to Visual Studio extensibility can be done with a VSIX directly, so presume there's a good way to do something that way before falling back to an MSI. Internally, we can register the entire C# and VB language services with just a VSIX -- they're quite powerful.
I found the answer in this link Registering Project and Item Templates. I set projecttemplatedir entry with
[User]\Documents\Visual Studio 2013\Templates\ProjectTemplates[Name of new Project Type][projecttemplate.zip] that is where i put the project template.
I have created a winforms app and a setup and deployment project for that app (VS 2010).
All I need is this:
When a user runs the msi, right after he selects the installation folder I want to check if the main executable of the application already exists in that folder. In that case I want to break the installation and prompt the user to either uninstall the existing application or choose a different folder.
I would like, if possible, to not use any custom installer action. At first, a launch condition (with a file search) seemed to be the right way, but it seems launch conditions (since they are 'launch') run at the beginning of the msi execution and not after folder picking.
Visual Studio Setup and Deployment Projects don't support this type of authoring. It's one of the many reasons that Microsoft removed that project type from Visual Studio 2012.
The only way to do it using this tool would be to build an MSI and then use ORCA to create a transform authoring the validation custom action and scheduling it into the UI as a gating control event. You could then write a postbuild script to apply the transform to the MSI every time it gets built.
Very advanced stuff and frankly not worth the effort. It would be far more beneficial to switch to a tool that supports doing this such as Windows Installer XML (FOSS) or InstallShield 2012 Professional. ($$)
I have a Visual Studio Setup project which has a Application Folder DefaultLocation set to[ProgramFilesFolder][Manufacturer]\[ProductName]. I would like to change this to include the software's version number, like [ProgramFilesFolder][Manufacturer]\[ProductName][Version], but Visual Studio doesn't seem to support it.
Is there an alternative to manually changing the Application Folder's DefaultLocation every time I create a new release?
You can use [ProductVersion] in the same way as [ProductName] and set product's version in the project's properties window.
The way I would do it is create a post-build event, that runs a Javascript program that modifies the MSI. It should be a pretty simple thing.
There's a sample script that modifies an MSI in the answers to the question
How to run an EXE after MSI installation?
That script doesn't do what you want but using Orca and that script, you should be able to figure out how to create your own, that modifies the MSI to insert the version number automatically.
It should be a single db update.
You have [ProgramFilesFolder][Manufacturer]\[ProductName][Version]
Try [ProgramFilesFolder][Manufacturer]\[ProductName]\[ProductVersion]
In particular, note the slash after [ProductName]