Within my project I create backup-files with a custom extension ".tp"
The software will be distributed with a Setup Project as an installer.
Which steps do I have to follow in order to add a registry entry via Setup project to let the OS show my custom icon? Is that possible?
I found a few solutions on how to do it manually, but I would like to have the installer (Setup project) to do it for me...
Could not find anything on that...
info:
I use Visual Studio Express 2017
Software is written in C#
EDIT:
In the meantime I was able to add a registry entry into the right directory, but I am not sure how to point to the .ico file, and on how to call SHChangeNotify...
Visual Studio setup projects have a File Types on Target Machine editor, so there's no need for registry manipulation. If you add a new file type (your .tp) the IDE's property window on the .tp (hit F4) will show a window where you add your icon. The %Open properties window is where you add the program to open the extension. It's not overly complicated. This seems to cover it in extra detail:
http://www.dreamincode.net/forums/topic/58005-file-associations-in-visual-studio/
Related
I'm trying to create a Visual Studio 2017 extension, just for fun and to learn how VS extensibility works.
My extension must be usable from the Solution Explorer tab as a context menu button, but I would like to include it at a menu level that isn't root.
My goal is to put it in the "Add" sub-menu, but at the moment I'm only able to put it at root level (when you right-click the Project item, the menu entry is shown as the last of the context menu control).
How can I move it under the "Add" node?
Can it be done from the CommandPlacement tags I have configured in my .vsct file?
Use as parent of your command the IDG_VS_CTXT_PROJECT_ADD_ITEMS group id. If you are using CommandPlacement it would be:
<CommandPlacement guid="..." id="..." priority="0x0001" >
<Parent guid="guidSHLMainMenu" id="IDG_VS_CTXT_PROJECT_ADD_ITEMS"/>
</CommandPlacement>
Remember:
The parent of a group can be another group, a menu, a toolbar, a context menu, etc. either created by your extension or an existing one of VS, identified by prefix "IDM_". See GUIDs and IDs of Visual Studio menus and GUIDs and IDs of Visual Studio toolbars.
The parent of a command is always a group, never a menu, context menu or toolbar. The group can be new (created by your extension) or an existing group of Visual Studio, identified by prefix "IDG_". You have some built-in Visual Studio groups in the links above, but for a more exhaustive list install the ExtensionTools extension (Mads Kristensen) that provides intellisense in the .vsct file or check the source code of its VsctBuiltInCache.cs file.
I think and hope this might help, though it is a general answer and not a specific one. Learn by example.
I also hope the WiX authors won't mind, but I believe the source for their Visual Studio integration component "WiX Votive" is here: https://github.com/wixtoolset/VisualStudioExtension.
There is also this: https://github.com/wixtoolset/VisualStudio.wixext. I am not sure what this is to be honest. I should, but I don't. Mr.Arnson - I summon theee (WiX developer - The Matrix's got you).
WiX Votive - VS Integration is part of the overall WiX Toolset - which is a Windows Installer deployment solution capable of compiling MSI files from XML markup. MSI files are the binary deployment files used by Windows Installer for deployment on Windows.
If of interest you 1) download and install WiX itself (currently 3.11.1), and 2) download and install the correct Visual Studio integration (the marketplace links underneath the main download) making sure you get the correct version for your Visual Studio version - of course. Both downloads from the same link (or use the Visual Studio marketplace).
Here are some further details: WiX quick-overview.
I am brand new to building and deploying Windows Forms applications, so new that I'm not even sure "build" and "deploy" are the correct terms. I read this excellent guide to creating an installer for my application, and I mimicked it almost exactly.
I have a winform project UmfExtract and a setup project UmfExtractSetup that installs UmfExtract . After installation, however, on Windows 10, an icon appears at the top of the start menu, under Recently Added: "Shortcut to Primary output from UmfExtract (Active)." I want to rename that to just "Shortcut to UmfExtract" or just "UmfExtract." Additionally, in the installation directory, the .exe and the .exe.config are the same as the original name of my project when I first created it, PythonExecuter. How do I change PythonExecuter.exe to UmfExtract.exe? Elsewhere on the user's computer, the application is named correctly. On the desktop, the shortcut icon says "UmfExtract," which is correct.
In all my research on this, people have said to change the Assembly name. I have done that. The Assembly name is UmfExtract:
I looked into the Outputs property of the Primary output object:
The AssemblyTitle and AssemblyProduct in AssemblyInfo.cs have been changed to UmfExtract:
What else could I possibly be missing? Could I perhaps accidentally be installing an older build of my project? I right-click on each project in the Solution Explorer and click Build (while the Debug/Release drop down box in Visual Studio is set to Release), then I navigate to the Setup project on my local machine and go to \Release\UmfExtractSetup.msi. I imagine that .msi file is updated/overwritten to the new information each time I Build the projects. Could it be that I'm building wrong?
I'm not 100% sure what was wrong, but the problem has been fixed. I believe the error was in the build process. I believe I was installing an old build of the project. I clicked Build > Clean Solution from the menu bar, then Build > Build Solution. I also right-clicked the UmfExtract project and then clicked Clean, then Build, and I also right-clicked the UmfExtractSetup project and then clicked Build (there was no Clean option in the right-click menu for the Setup project).
(Using VS 2010 with a Visual Studio Installer project.)
I have added a 'Checkboxes(A)' dialog to the 'User Interface' under the 'Start | Welcome' dialog and set a checkbox with the property set to "DESKTOPICON". The option is being displayed.
In the 'File System' the 'User's Desktop' has the condition property set to DESKTOPICON=1.
When I run the install on my VM the option appears to be ignored and the desktop shortcut under the User's Desktop list is always installed.
I looked at these similar posts but it does not seem to work for the desktop icon?
How do I specify Visual Studion Installer Conditions?
Visual Studio Deployment Project Optional Desktop Shortcut
Is it normal for the User's Desktop to ignore it's condition property or am I doing something wrong?
Visual Studio setup projects create only shortcuts to installed files. This type of shortcuts are linked to their target and share the same component.
Since in Windows Installer you can condition only components and features, you cannot condition a shortcut directly.
A common approach is to write a custom action which removes the shortcut. You can then condition the action instead of the actual shortcut or its folder.
Well, I know it's been a long time but today I faced exactly the same issue as mentioned. I wanted to try creating a windows installer in VS 2013 using "Installer Projects" extension thing and wanted to make a checkbox with condition whether create a desktop shortcut or not.
Like above, shortcut under User's Desktop was always installed.
After wasting almost 3 hours I found a workaround on the old Microsoft Connect feedback post: (which apparently was already dead for some time)
Ok I got this to work by adding the main file twice to the folder (the
file you are creating your shortcut to). I tie the shortcut to one of
the files and on that file I set the condition to CHECKBOXA1=1 so it
will only create that file and the shortcut if they check the the
"Create Shortcut" box. For the other file I set the condition to
CHECKBOXA1<>1 so it will create it when the check box is anything but
1 (not checked).
originally posted by Chancea on 7/1/2010
I tried to do it that way - it works as intended. Not really convenient whatsoever (can mix up the same looking names etc). For a really, really simple installer thing (which I needed) with an only additional feature, adding shortcut to desktop, it might be fine however.
Nevertheless I still think it only proves that this is just a port of an Installer Project from earlier versions of Visual Studio, now added by an extension.
The idea may be good and useful I think, but I wish they fixed just some of the Windows Installer project in VS issues and lack of features.
Like I said, it would be great option for people (... like me) who want to publish some pretty small and lightweight apps, and needs only some basic features from the installer like (optional desktop shortcut, adding to startup, installing some additional files etc etc).
Well, I guess the conclusion is that I'd just have to start learning WiX or try out the InstallShield
After another 2 1/2 years in VS2019: The problem remains that the shortcut created in the "User's Desktop" folder can not handle the condition imposed by the checkbox. Thus a somewhat simpler (but also not "clean") solution would be not to duplicate the exe (e.g. myApp.exe) like in Skippers solution (it did not work for me), but to create an additional myApp.bat file doing nothing but starting the myApp.exe.
The simplification consists in the fact that only a condition on the myApp.bat file is necessary, and no one on the myApp.exe file.
The following steps worked here:
Create a myApp.bat file doing nothing but starting myApp.exe, i.e. containing the single line "myApp.exe" (without the quotes). Of course, commandline parameters would be possible if necessary.
Put myApp.bat into the "Application Folder" of your installer project.
Set the condition on myApp.bat to CHECKBOXA1=1, meaning it is created only in case of the CHECKBOXA1 having been set.
In the "User's Desktop" folder of the installer project, create a shortcut to myApp.bat (Context menu "Create new shortcut"), give it the icon of your app ("Icon" property). Do not specify a condition. Here in my case (VS2019 on Win10) this resulted in a NOP action when the myApp.bat was not created (checkbox unchecked), and properly created the link on the desktop when myApp.bat was present (checkbox checked).
For this shortcut, you might wish to set the "ShowCmd" property to vsdscMinimized, to avoid the large command line window of the bat file.
Hi I'm trying to get an optional desktop shortcut integrated with a VS2010 deployment project. I'm at the part where I have set added a shortcut to the "User's Desktop" of the TargetMachine file system, and I have set up a Checkboxes Dialog in the User Interface. How do you get the Checkbox1Property to transfer over as a conditional for creating a shortcut to the desktop? I don't see any options to add a conditional statement that can link the Checkbox1Property when I view the property for the shortcut in the targetmachine file system. The shortcut is always created as of now.
Thanks
For a complete understanding of this, I'd recommend reading:
http://www.codeproject.com/KB/install/vsSetupCustomDialogs.aspx
In short, you've already added the shortcut and created a new dialog window from the "View" -> "User Interface". All that's left is setting the condition property. You can't change this property of the shortcut itself, but you can change it for "User's Desktop".
For that condition you might want: CHECKBOXA1=1 which means the item is created/activated only if the CHECKBOXA1 is checked. 0 for unchecked.
A reference to conditional syntax is here:
http://msdn.microsoft.com/en-us/library/aa368012.aspx
EDIT : I just tested this and it looks like the Visual Studio installer is pretty unintuitive. The answer I provided doesn't work. You have to go about this is an ass-backawards way. This article better describes the process than I can: How do I specify Visual Studio Installer Conditions?
Overall, the Visual Studio installer is intended for fairly vanilla installs. It can do a LOT more, but it's cumbersome to do so. You can even have custom actions run during the installation (ie: run your own executables). The Visual Studio installer is included with VS 2010, but it will be removed in favor of InstallShield LE in future version.
I've created a windows service in C#, using Visual Studio 2008
I pretty much followed this:
http://www.codeproject.com/KB/dotnet/simplewindowsservice.aspx
I created a setup project, as instructed to in the article, and ran it...
it installs my service to C:\Program Files\Product etc.... however, it does not then appear in the services list..
What am I missing?
The most important part of the article you linked, is here
To add a custom action to the setup project
1.In Solution Explorer, right-click the setup project, point to View, then
choose Custom Actions. The Custom
Actions editor appears.
2.In the Custom Actions editor, right-click the Custom Actions node
and choose Add Custom Action. The
Select Item in Project dialog box
appears.
3.Double-click the application folder in the list box to open it, select
primary output from MyNewService
(Active), and click OK. The primary
output is added to all four nodes of
the custom actions � Install, Commit,
Rollback, and Uninstall.
4.Build the setup project.
If you skip these steps, your setup project will build and copy your files to the correct directory; however, they will not register your binary as a service without these steps.
I should also note that this works for older versions of Visual Studio that had/have the built-in Setup/Deployment project template. The newer versions of Visual Studio have different setup/deployment projects (some requiring third party software.)
I'd recommend looking into WiX Toolset and check here for WiX Installation of Windows Services.
I got owned in the face by this one, so I'm putting it here just in case anyone else runs into it.
If you followed the instructions in the guides but are still having issues installing, ensure your Installer class is public. Internal won't work.
I had this same issue and then I realized that I never set the parent for the ServiceInstaller.
Double-click on your project installer. The designer should show a Service Installer and Process Installer. When you click on either and view the properties you should note the Parent attribute which must both be set to the class name of the Project Installer.
Or, if you do it in code, make sure you set:
serviceInstaller.Parent = this;
and
serviceProcessInstaller.Parent = this;
When installing services, I would highly recommend using NSSM, which worked well for me for all my WinService needs. It can install any executable (even if .bat, .cmd) as a service, and guarantees your service is always up and running.
To use this tool:
Download from here
And follow the instructions here
Then check the services list, it should be there, up, and running.
Follow these instructions, they worked for me. For the setup specifically, that part is near the bottom of the article.
MSDN: Walkthrough: Creating a Windows Service
In Visual Studio 2013 I ran into the same problem using InstallShield template for service application. But it works like charm when using Setup Project template https://visualstudiogallery.msdn.microsoft.com/9abe329c-9bba-44a1-be59-0fbf6151054d
so download Setup Project template close your Studio, run this installation and start your Studio, this will work.
Dunn.
Here is a good tutorial from tgeek001 from CodeProject.com that helped me. It includes several things I didn't see in the posts above:
1. Event handler code to stop the service before uninstalling it
2. Specific conditions and properties in the Custom Actions code to set in order to prevent failures (these fixed the Error 1001 that I experienced while following the instructions in the accepted answer above)
3. Win Service property "Remove Previous Version" dropdown set to true
http://www.codeproject.com/Tips/575177/Window-Service-Deployment-using-VS
The following is from the tutorial for Custom Actions Settings (case matters):
Install, set the Condition property to the following: "NOT (Installed or PREVIOUSVERSIONSINSTALLED)"
Uninstall, set the Condition property to: "NOT UPGRADINGPRODUCTCODE"
Commit: set "Custom Action Data" field to: /OldProductCode="[PREVIOUSVERSIONSINSTALLED]"
Lastly, in the WinService project, make sure to set the dropdown "Remove Previous Versions" to true.
cheers
I discovered that your installer class much be in the same project as the Service. The installer cannot exist in a library project referenced by the Service.
remember to check the name you've given your service before you search. (right click-> properties->check the service name