Can you install a program for "All Users" using Visual Studio ClickOnce Publishing?
I ran setup and was not given the option "Install for All users" => then I inspected the actual install directory and it was in the folder:
C:\Users\Patrick\AppData\Local\Apps\2.0\Z5AWACYL.000\4EQB7LVJ.RXP\mapl..tion_0000000000000000_0001.0000_d31e4ada0d11807b\
So I think no other user will be allowed to run it. How does one create a project installer that installs a program to all users?
After a bunch of research the answer is No.
I figured out a really hack way to pull it off. But it caused problems in production, specifically, I got calls from this guy, and he's like "Do I have to install the app for every user?", Then later he would say, "User1 is running version X.X.X.1, but user2 is running X.X.X.2" So it was a lot of work for disappointing results.
Have you taken a look at this? http://msdn.microsoft.com/en-us/library/dd997001.aspx
Related
I installed the software openDylan (windows 32 bit) but I can't run any program on it.
I created a project and when I compile the project I get the following error:
building targets: exe
don't know how to build <hello>library.obj
What do I do so I can pool run software projects?
I've fixed a couple of things since the 2012.1 release and hope to do more for the 2013.1 release, but:
Install Pelles C from http://www.smorgasbordet.com/pellesc/ if you
haven't already.
Inside the Open Dylan IDE, there's a settings dialog that lets you
choose a build script and you'll want to select the
x86-win32-pellesc-build.jam file from within C:\Program Files\Open Dylan\lib\.
Run the Open Dylan IDE from within a Pelles C command prompt. The IDE is C:\Program Files\Open Dylan\bin\win32-environment.exe.
I don't have Windows on the machine that I'm using at the moment, so I can't confirm the exact / correct paths, but hopefully I haven't made any terrible errors.
With that, things should work, including debugging.
We definitely need some improvements on Windows and we'd be happy to help you get going. (You can also chat with us on #dylan on Freenode IRC.)
As part of our nightly build on windows, an installer package is created using NSIS. I would like to automatically test the "correctness" of the installer.
This might be things like:
Checking the platform of dll files.
Checking the install folder.
Testing the uninstall function doesn't leave any files behind.
Checking registry keys are created in the right location.
Are there any tools or techniques that could help me achieve this?
I don't think VM's or automated processes to push the package to the VM is an answer in itself. The real problem here is 'How do you know the integrated / deployed product will work?' I think the only answer to that question at this point would be to then have automated processes to test the application itself in the deployed state.
I'm going to build an installer to deploy my application which is a Windows executable file(not a MSI file). I'm using NSIS. This application targets French people and "install" word is close to "installation" in French.
Is there a filename convention? What is the best choice for you?
It seems that "setup.exe" is the most popular name compare to "install.exe"
What do you think?
Thanks for your reply.
Sometimes setup.exe is used for install, repair and remove application. I think there is no good answer for this question. I prefer such names as application_installer or application_setup. Even in one organization there is Firefox Setup 3.5.6.exe and sunbird-0.3.pl.win32.installer.exe.
setup.exe is definitely the most popular convention in the Windows world. I'd say go with that.
I'd never really thought about it... but having done just that - setup is really the wrong word and install is, I suppose, the correct term.
You're installing the software, so I would go with install... setup implies it has already been installed (unless your changing settings during the install) - either way you are still installing something.
I am starting to do some installer work using WiX (yay, not Installshield) and I was hoping to do some TDD of the installer. Does anybody know of an easy way to do this?
It sounds to me more like an integration test than TDD.
As far as i can tell there are no MSI testing suits per se.
Nevertheless you could try something like this ( assuming you have a contiunous integration server):
after successful build, install MSI on a clean virtual machine - if installation fails do something (mail, ticket, whatever)
run whatever integration tests you have on your project
After that you can be sure that installed application does what it should.
Does it make sence, if you create some script file that checks that files are on the right places. I expect make it as perl or python script
test_installer_wix.pl
msiexec /x product.msi # remove
msiexec /i product.msi /silent # install
ASSERT_EXIST_FILE(PFILE, 'productname/application.exe')
ASSERT_REGKEY_EXISTS()
and etc.
I want to add link to post about how to create unit test for WIX installer database: http://miroslawmiodonski.blogspot.com/2012/10/how-to-create-unit-test-for-wix.html
It might not be a bad idea to run a few standard tests on a generated MSI. MSI files support a lot of different deployment scenarios: admin install to extract files, advertised install for active directory, silent install, maintenance install, uninstall etc... Maybe it is indeed an idea to create a small test suite for this - perhaps it's even being considered for the WIX toolset for all I know.
However, I think the first, best step towards delivering a quality setup would be to run the MSI through the MSI validation suite. These are referred to as ICE (Internal Consistency Evaluators) and they are delivered as *.cub file with the Windows Installer SDK. Running these scripts tend to reveal lots of bad design constructs in the MSI. The WIX tool for this is called smoke.exe.
I am creating a Visual Studio Setup project. I want to un-install another component from the system from the install of my component. The other component is installed from my own setup created using Visual Studio.
Currently when I am calling the un-install of the other component from the install action of the component I get the error code: 1618 (another MSI already running).
Could anyone suggest me an alternative way to solve this problem?
If you don't need to actually run the uninstall of the other component, you could use a Custom Action to remove files/folders you intend to replace.
Using a Custom Action will force you to do all the clean up actions the Uninstaller would do for you.
Is it that you're replacing something or are you just trying to uninstall something as a result of installing something entirely different?
MSDN Custom Action Walkthrough
I have also read a few articles from Phil Wilson that have been helpful with Custom Actions:
Phil Wilson on Custom Actions
I ran into a similar problem that required several installs to run together and could find no way to run MsiExec recursively. The solution I used was to bundle the installer with a script that would run MsiExec once to install/uninstall the old package, then again to run the new installer. Clients had to run the script to install.
If you find a better way, let me know.
I think you can run uninst.exe of that program through the shell command while setup starts.....