Heyy all =)
We create a custom project template in C# following This topic to force all developers to develop uniformly, all inherit from the same class and receive the same development tools we developed in four separate DLLs and all have the App.config file with default keys etc.
We work on vs2012 or vs2013.
Since I have put the DLLs manually and attach them to come into the same project ZIP file (are that is the right way to do it or somthing like this answare?) Now if there are any changes we will have time to re-export it, etc. So we thought the installation project.
Now I'm not sure what type of project to use.
I saw that there are a number of options I will list below and I would love advice about the right, the best, and most appropriate way to do it:
Creating Extensions By Using the VSIX Project Template or other Extensibility projects
The WIX way
Using Wizards somthing like this perfect answare
One of the project from the Visual Studio Installer Projects Extension
Related
For example, I use Visual Studio to create a mono game project in the solution, and I add another wix project that
when I hit "build solution", the mono game project being build, and wix project build a installer directly afterward.
In this way, I don't need to separate my project everywhere, because I just want some more additional options with One-Click installer.
If I can use Wix, I can customize the installer, but how?
After search for some time, I found this
http://wixtoolset.org/documentation/manual/v3/votive/votive_project_references.html
But, I would like to put two projects in a same solution folder, rather than two separate solution folder. This way, if I change the path, will the link just broke up?
Yes, you can. Simply add a reference to the project from your WIX project.
Note that with project references, you can use variables in your wxs files. For example if your game project were DavidWong.MyGame:
<File Id="MyGame.exe"
Name="$(var.DavidWong.MyGame.TargetFileName)"
Source="$(var.DavidWong.MyGame.TargetPath)" KeyPath="yes" />
See the documentation for more info.
Yes, it can be done ( project reference and $(var.ProjectName.TargetDir) and so on ) but in my experience there are a few reasons not to:
1) When a new version of Visual Studio comes out you might be stuck if a new version of WiX is not yet released to support that version of Visual Studio. I've seen this several times and currently you'd have to run a beta build of WiX v3.10 if you wanted to support Visual Studio 2015.
2) All developers now have to install WiX or get error messages that some projects couldn't be loaded.
3) Some developers will complain that they don't want "setup" code in their .NET solution. I think this is a thin complaint but I kinda get it.
What I like to do is have an application solution and an installer solution. I use postbuild copy commands and MSBuild publish profiles to stage content in a "deploy" folder that models the deployed system and then use that reference that structure in my wix code.
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.
Sometimes I've seen a solution that includes up to three .csproj files for each project in the solution. Something like this:
Project.UI.2005.csproj
Project.UI.2008.csproj
Project.UI.2010.csproj
and the same with .sln files:
ProjectSolution.2005.sln
ProjectSolution.2008.sln
ProjectSolution.2010.sln
So if you copy the solution and want to open it using VS2005, you just need to open Project.UI.2005.csproj or ProjectSolution.2005.sln.
What is the best way of creating those 3 (or 2) files, in order to be able to open the same solution in multiple versions of Visual Studio?
Maybe the only way of doing this is modifying manually the .sln/.csproj. If so:
How can I modify those files correctly so I won't crash the solution?
I want to do this because sometimes I develop applications using VS2010 and when deploying the source code to my customers, they can't open it in VS2008, and then I have to do some tweaks.
Note:
I know there will be referencing and compiling problems if I use features only included in .NET Framework v4.0, or similar. Let's suppose all the projects in the solution are compiling under .NET Framework 2.0 (specified in the project properties).
I finally ended developing a small application do to this.
I'm still testing it, but it is working good so far.
All you need to do is, select the .sln file you want to convert, and specify the versions involved in the conversion, and it will do all the work for you.
If you have a VS 2010 project:
Solution (Solution.sln)
Project_1 (Project_1.csproj)
Project_2 (Project_2.csproj)
and you want downgrade the version (to 2008), it will keep those files, and also create:
Solution.2008.sln
Project_1.2008.csproj
Project_2.2008.csproj
And you will be able to open Solution.2008.sln with Visual Studio 2008 without problems.
As soon as I finish it, I'll share executables and sources here.
Can someone briefly explain to me the difference between Visual Studio's solution file (.sln) and project file (.vcproj).
It seems to me opening either one open the correct solution/project in Visual Studio. Is one the super-set of the other?
Note: I am currently using Visual Studio 2008 working on a project that was brought forward from Visual Studio 2005 (I believe).
A solution is a set of projects. If you need more than one project in your software, then go with solutions. I.E.: A Class Library Project + A Web Application Project.
A project file typically corresponds to a single module: EXE or DLL or LIB. A solution manages a collection of project files.
A solution is a collection of projects. Visual Studio is made so that it cannot function without a solution, so if you open a bare project, it will generate the solution automatically (or try to find one).
One solution can contain zero or more projects. Everything is in projects, so a solution with zero projects doesn't contain anything at all besides the solution properties.
Visual studio keeps track of where the projects are used, so if you open a project file, it will open (IIRC) the last solution where it was used.
When you create a project from scratch, a solution is also created, but it's not shown until you add another project to it. It looks like you have only the project open, but it's actually a solution containing the project that is open.
Specifically project files are intended to contain the data required to build the files in the project into an exe or dll. This file is utilized by the local compilers or with systems such as Team Foundation system and server side build agents.
Solutions are a client (IDE) construct designed to manage collections of projects, which in effect is a collection of different build definitions and associated files.
Solution files are typically made up of multiple project files.
We've been using Visual Studio 2005 Team Suite for a fairly large web project. Now, we're adding another web app into our current project...it is essentially complete, and we're just adding the entire thing as a folder into our current project. The project builds, runs...everything is fine...but this new sub-project doesn't have any kind of Intellisense that recognizes the classes we've created for this sub-project.
I think that this is probably because the code for the project isn't in the App_Code folder, and so Visual Studio doesn't know where to find it. Does that make sense? If so, what can I do about it?
As fas as I know, that's just the way it is. For some reason, the default template for web apps in 2005 does it like this. If you just need small stuff, making the classes not in App_Code implement an interface, and then just use this when you interact with your code that reside somewhere outside of App_Code (for whatever reasons).
Otherwise, you can choose to use a different project model (doesn't ship with 2005, so need to be installed seperatly, and conversion could be non-trivial):
http://webproject.scottgu.com/CSharp/Migration2/Migration2.aspx