I'm building an installer for a Visual Studio 2010 solution and I've decided to go with WiX. I've added the WiX setup project to the solution and am trying to configure it in a similar fashion to the rest of the projects in the solution.
The way those projects are setup is that their project files are in a seperate directory from the rest of the source:
Source
Core
UI
Projects <- .vcproj files for the Core and UI projects are in this directory
...
Now the new project for the WiX installer is called Setup so the directory tree now looks like:
Source
Core
UI
Setup
Projects <- .wixproj for Setup is here, and I want it's source files in the Setup directory
...
The problem is that whenever I add a source file to the Setup project, it copies the file from where it is to the Projects directory, next to the .wixproj file.
Is there something I can set on the project to prevent this behaviour and include WiX source files in-place?
Bryan's comment basically covered it:
You could also open the .wixproj in an xml editor and add the files by editing the xml (see how the other files you linked to the project appear). That seems more complicated, but may be less tedious if you have a very large number of source files to add.
Related
I wrote a C# windows service project and a related setup project in the same solution named MailTrigger. But after I built the whole program, there is two folders, "MailTrigger" and "MailTriggerSetup"(as I named the setup project). My problem is how can I set the two project to be in the same folder?
When you have a solution, you will have individual project directories under your solution directory. You have the ability with the setup project to tell it where to put the created binaries. I am not sure what specifically you are wanting, all of the files in one folder without any delineation between your main project and your setup?(which will not work) or just wanting your msi files in the same folder as your main projects code?
Edit: I was able to get a directory structure that looks like:
By moving the MailTriggerSetup Directory into the MailTrigger Directory and editing the MailTrigger.sln file's project settings with notepad to look like this, also just change the file paths not the Guid's :
Microsoft Visual Studio Solution File, Format Version 11.00
# Visual Studio 2010
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "MailTrigger", "MailTrigger\MailTrigger.csproj", "{FD22977F-584D-4707-9B10-35482B91C450}"
EndProject
Project("{54435603-DBB4-11D2-8724-00A0C9A8B90C}") = "MailTriggerSetup", "MailTrigger\MailTriggerSetup\MailTriggerSetup.vdproj", "{15C4C96E-EF6A-44DB- BDFB-8AEE2C05289E}"
EndProject
Some caution needs to be taken since you are directly editing the solution file, Please backup your data before trying this.
We need to create a new project in Visual Source safe. This project is actually a newer version of an existing project. Following is what we want.
All files of existing project are copied to new project.
Files in both projects are not shared. (Changing a file in one project should not affect the same file in other project)
All Visual Studio solutions and projects are bound to new project in source safe.
Whats is the best and easiest way of doing this?
You should use the share and branch option...
MSDN help (works with folders as well as files)
This will break the link between the two copies meaning that you can change files in one project without affecting the other one.
I have several Visual Studio web application projects that include SVN externals. When a new file is added to an external module, VisualSVN brings it down to the file system, but doesn't add it to the Visual Studio project; it has to be manually added.
I might write a macro to automate this process, and I'm wondering if I can make it a one-step process by either:
Having the macro initiate the VisualSVN update, then do the work (Q: Is it possible to trigger a VisualSVN update from a macro?)
Hooking into a hypothetical "post-update" event from VisualSVN to fire a macro to do the work (Q: Does such an event exist?)
I assume you are currently working like this: your "external modules" are just a loose collection of source files without a project file. Whenever a source file is added, you update all your application project files by adding the new source file, so that it is compiled into all the application assemblies.
I think you are doing it wrong. Your project solution file should contain a reference to a separate visual studio project file for each external. Each source file should be compiled into exactly one assembly.
For example, you might have a C# library shared between multiple web applications. This library has its own .csproj project file, which lives in the external location. If a source file is added to the library, the .csproj is updated. The updated .csproj file is then pulled it via an svn:externals declaration when you update your project.
If a VS2008 project is created initially with a web app project, and class projects are added, and the structure is like this:
Parent Folder
Web App Project Folder - (solution Files in this folder)
Class Project 1
Class Project 2
...
do you see any problems with moving the .sln and .suo files to the parent directory?
Parent Folder - (solution Files in this folder)
Web App Project Folder
Class Project 1
Class Project 2
...
I adjusted the .sln project directories and the solution seems to be working fine, but I'm wondering if this action will break something I didn't anticipate.
Only the project files determine their build outputs - solutions only link projects together into a logical entity, so that they can be loaded at the same time in a Visual Studio instance. If the projects are still the same, nothing's broken.
And the .suo file can be safely deleted. It's a user-specific file that simply retains a particular user's options for a solution. It contains nothing that's important to projects, build settings etc.
You can open your .sln file with whatever editor you'd like, even notepad, and see that it contains only references to your project files in it, you can modify it so that the relative paths to your project files in it match your layout. VS wouldn't have anything against it.
All build settings are stored in project files, so you don't loose any configuration changes you've done in your projects.
Visual Studio projects assumes all files belonging to the project are situated in the same directory as the project file, or one underneath it.
For a particular project (in the non-Visual Studio sense) this is not what I want. I want to store the MSVC-specific files in another folder, because there might be other ways to build the application as well, for example with SCons. Also all the stuff MSVC splurts out clutters the source directory.
Example:
/source
/scons
/msvc <- here is where I want my MSVC-specific stuff
I can add the files, in Explorer, to the source directory manually, and then link them in Visual Studio with the project. It's not the end of the world, but it annoys me a bit that Visual Studio tries to dictate the folder structure of my project.
I was looking through the schemas for the project files but realized that this annoying assumption is in the IDE and not the format of the project files.
Do someone know a neater way to solve this than manually linking files to the project from the source directory?
I use this sometimes, pretty sure it's what you want:
make sure the Show All Files option is on in your solution explorer.
create a symlink that targets your source directory and put the link at the same level as your project, or even lower if you want finer control. The command is mklink /j target source
For the example project structure you show, you'd run mklink /msvc/source /source and in the project the source directory will show up as if it was in the project dir (well, actually it is). Additional bonus: adding new items through VS also automatically puts them in the right directory.
You can add files with links like this, they are searchable, view-able, but they do not checkout if you try to change them, also visual studio leaves the wildcards in place:
<ItemGroup>
<Content Include="..\Database Schema\Views\*.sql">
<Link>Views\*.sql</Link>
</Content>
</ItemGroup>
This goes inside the .proj file.