This question already has answers here:
Visual Studio 2017 setup project missing
(6 answers)
VS2017 Setup Project - Where?
(2 answers)
Closed 4 years ago.
I'm wondering how to use Setup Project in Visual Studio 15, which was in
Solution -> Add -> New Project -> .../installed -> Other Project -> Types -> Visual Studio Installer ->Setup Project
but this disappeared. To create an .EXE file for a Windows Form Desktop application, it seems like it is no longer available.
Or how can I access the same functionality with higher versions?
There is an extension that brings it back for backwards compatibility. But at the same time the guidance has been to finally move to a Wix installer or some other installer technology.
The Installer projects are considered deprecated and bad. They can't be easily built using a CI server and more issues.
The proper solution would be:
Use Wix Installer project (if you need Visual Studio project support)
Simple tutorial
Pluralsight
Use something like NullSoft Installer (just build the installer by building it outside of Visual Studio.
If you have an existing investment in the old style installer projects, you can still use the extension. If you're building something new. DON'T. It may be the simplest way of adding an installer, but it'll cause more issues in the long run.
Related
I need to create a WPF app using the Surface SDK. I am using Visual Studio 2012, and according to this SO post, VS2012 doesn't allow that. However, since this was posted before it was officially released, I want to make sure I'm not missing something.
I just need a few of the touch/swipe controls that come with it. Is there a different option for VS2012? The other developer is using 2010, so it needs to be able to still run on his machine. It's a very simple app that I just need to hammer out, so I'm looking for the fastest, easiest method. Both of us and the end application is to run on Windows 7.
I found an easy solution by which it seems to work. It does expect you to have Visual Studio 2010 installed. Following the following steps I managed to compile in Visual Studio 2012 using .NET 4.5. TouchDown events work. I tried it out on some small projects and they seem to work perfectly fine.
Use Visual Studio 2010 to set up a Surface project.
Safe and close Visual Studio 2010.
Open the solution using Visual Studio 2012.
Change the target framework under project settings to .NET 4.5.
Save as a new solution file.
Compile, ... everything works!
This method prevents you from having to set up all the configuration files/references yourself. The only downside is you don't have any of the Surface tools integrated into the IDE. E.g. the toolbox, project templates, ... This of course doesn't prevent you from writing plain XAML yourself.
If for some reason this doesn't work in the long run I will update this post.
The easiest way will unfortunately be for you to run VS2010.
Currently the SDK is not supported in VS2012, for a few reasons.
Notably, the way that touch works in Win8 is a lot better than in previous versions of Windows. This unfortunately meant a rewrite of the touch layer that the Surface SDK uses. The new controls are written to adapt dynamically based on mouse/touch input, making the Surface SDK controls a bit redundant.
Microsoft might make the SDK available for VS2012 in the future, but this is kind of debatable.
If you are still dead set on giving it a shot, download an application called Orca (http://msdn.microsoft.com/en-us/library/windows/desktop/aa370557(v=vs.85).aspx) and edit the SDK installer file, removing the dependency on VS2010.
This is how I got the Surface 1 SDK to work with VS2010, since it was targeting VS2008 (note that it still has not been updated to work with VS2010)
Let me know how you go.
I have a VS 2010 C# "solution"; It creates an .exe file, and a .pdb file when doing a build in Release mode which I use in the InnoSetup build of the installer.
My app uses several .dll's from other vendors (i.e. WinSCP). My question is: do still build the installer using InnoSetup, substituting the new .exe from .NET Reactor for the one created by Visual Studio? The only thing I want to obfuscate using .NET Reactor is my app, not the other vendors.
(I have looked in Google and SO, and did not find an answer.)
You could directly substitute the exe/dll before you build the installer.
In case you want to automatically protect a VS project file output (exe/dll) before it is packaged into your into you setup you could use the .NET Reactor Visual Studio Add-in.
Install dotFuscator then you will be able to add its project type in source code as new project. There you can set output files to obfuscate.
I've moved a C# project from Visual Studios 2008 Professional to Visual Studios 2010 Express.
It converted the project successfully with the VS migration wizard, but the build is failing.
There are quite a few errors, all having to do with the WPF Datagrid. The errors don't occur when built in VS2008. For example:
'DataGridRow' is an ambiguous reference between 'System.Windows.Controls.DataGridRow' and 'Microsoft.Windows.Controls.DataGridRow'
I see that the project also uses WPFTools.dll.
With VS2010 maybe WPFTools.dll is no longer needed? Or maybe I need to use the Professional version instead of the Express version of VS and the project wasn't successfully migrated?
I think I can edit all the places where this is a problem using the full namespace to make the error go away, specifying either "Microsoft.Windows.Controls" or "System.Windows.Controls", but I'm not sure which of the two it was defaulting to under VS2008.
This is most likely tied to the .NET FW version, ie...was this 3.5 prior and you migrated to 4? If so, you would have been using the WPFToolkit prior whereas the DataGrid is now part of the standard FW in 4 and greater.
Remove your references to the WPFToolkit and use the standard FW class and you should be fine.
I work on several projects with different development environments. I would like to maintain a Visual Studio 2008/Silverlight 3 environment on the same development workstation as a Visual Studio 2010/Silverlight 4 environment. If possible, I would like to be able to work on both at the same time, without using virtual machines.
Has anyone done that successfully? Is there anything special I need to do to help them coexist? I previously installed Silverlight 4, and it prevented me from working in the Visual Studio 2008/Silverlight 3 environment. But it is possible that I did something wrong in the setup.
I don't think the two can coexist next to each other. You will either need to make a VM with the specified configuration, or specify the SL version in Visual Studio.
Can you ellaborate why you can't run you SL3 project in VS 2008?
Could you use VS 2010 for your SL3 work? VS 2010 includes multi-targeting capabilities, and is compatible with Silverlight 3 out of the box. SL4 support is added with the SL4 development tools, so at that point it supports both.
You can pick which Silverlight version you want each project to be either at project creation time (for new projects), or in the project Properties (for existing projects).
I have just been informed that the Silverlight 4 Toolkit (latest download) requires the prior installation of VS 2010.
We are setting up an automated build server for a very large Silverlight Prism project and would prefer not to do a full install of VS 2010 on an unmanned build machine.
Is VS 2010 actually required for an install of the Silverlight 4 Toolkit?
Why is it required?
Is it possible to work around this (copy specific pieces from another Dev machine?)
Thanks in advance for any information.
The problem with this is that it doesn't install the msbuild tasks. I have found that it is possible to install just the SDK by extracting it from the tools download. For details see here: http://neilsleightholm.blogspot.com/2010/09/building-silverlight-4-applications.html.
Don't install the Toolkit at all. In these large controlled scenarios you would probably want to copy the toolkit dlls to folder owned by your change control system anyway.
Ultimately the toolkit is just a set of dlls. On install it does other things to make using it as a developer convenient in VS and Blend but it has no special requirements at build time.