I want TFS to build my projects into separate folders in Binaries folder. I have found the solution: http://blog.stangroome.com/2012/02/03/override-the-tfs-team-build-outdir-propert (I have to use .Net 4.0). However, I have mane projects in the solution and new projects may be developed by other developers, so I wouldn't like to change every *.csproj file by adding
<OutDir Condition=" '$(PreferredOutDir)' != '' ">$(PreferredOutDir)$(MSBuildProjectName)\</OutDir>
How could I add this line for every project automatically, for example in before.Foo.sln.targets?
You'll need to touch each one of your projects if you want an architectural solution that allows you to change this property globally from a single location.
Make a separate XML script file called "Common.targets" that is included as an and referenced by each of your projects after the first .
In each of your .csproj files, remove the property and add a after the first PropertyGroup, but make sure does not exist after this import.
Related
I'm writing a class library for a simple parser in C#. When I first created it, I used .NET standard 2.0, but now I need to migrate it to .NET 4.6 both to conform to the other projects in my solution and in order to use NUnit.
I tried to follow the instructions in the Microsoft documentation, but when I try to select another framework in the properties, I can only find other .NET standard versions.
How can I migrate it? Will I need to manually edit the .csproj file?
Open up the project file (.csproj) and change the TargetFramework to net462
<PropertyGroup>
<TargetFramework>net462</TargetFramework>
</PropertyGroup>
My personal experience in Visual Studio 2017 is that recreating project and adding existent sources is the simplest, safest and most effective way - because .Net Framework based csproj file has extra xml elements (comparing with Standard based), it seems changing "TargetFramework" is not enough.
Below is portion of diffs appeared by default:
If you are publishing your class library as a Nuget package then there is a better way to set this up. Check out this article:
https://weblog.west-wind.com/posts/2017/Jun/22/MultiTargeting-and-Porting-a-NET-Library-to-NET-Core-20
Basically you can setup your class library for multi targeting, allowing it to be imported into .net core projects as well as different versions of .net frameworks.
There are a few steps that I did and worked for me:
git push your code, so you have a back up :)
Unload the project in VS (right click on the project and unload)
Edit the project in VS (right click and edit)
Replace the TargetFramework OR/AND TargetFrameworkVersion with
<TargetFramework>netcoreapp2.0</TargetFramework>
Change the project line, that's usually the first line (after xml root) to:
<Project Sdk="Microsoft.NET.Sdk">
Remove the import that's usually the second line (after the xml root)
Keep your PropertyGroups that describe the build options, if you want (I want mine as are custom)
Remove the references and the file references, they are not needed.
Close the file and reload (right click reload).
Delete the assemblyinfo file (from properties folder) as it is not needed, the assembly version comes now from the proj
Right click on the project and go to properties to see that you don't have any error in proj file. Ensure that you don't have typos or tags that are not close.
Build. If you have dependencies that you are missing then right click and on the project and add them. - I suppose that you don't want to edit them in the proj. Or you can do a dotnet restore or dotnetbulid to add them, as you would like.
Hope this works for you. They seem a lot of steps but they are not that complicated, and this is one time effort.
I have added NCrunch to my .Net Core solution and now this file was added to all projects:
ProjectName.v3.ncrunchproject
I have added this to gitignore so it's not going to source control, but how can I remove it from Project?
There is an option of excluding this file explicitly in each and every project by either clicking Exclude in menu or adding it manually in .csproj file. I hope though that a better solution exists.
One way of solving this is to modify DefaultItemExcludes in sdk project props. For example go to:
C:\Program Files\dotnet\sdk\<version>\Sdks\Microsoft.NET.Sdk.Web.ProjectSystem\build\netstandard1.0
and modify Microsoft.NET.Sdk.Web.ProjectSystem.props.
Find something like:
<DefaultItemExcludes>$(DefaultItemExcludes);**\node_modules\**;node_modules\**</DefaultItemExcludes>
and change it to:
<DefaultItemExcludes>$(DefaultItemExcludes);**\node_modules\**;node_modules\**;**\*.ncrunchproject</DefaultItemExcludes>
After Visual Studio restart it should be automatically excluded from your project. This is not a perfect solution, because you will have to do it for every project type and sdk you have.
My situation:
I have a solution A with hundreds of projects,
Some of projects are class libraries and are referenced from other projects.
Now I want to create a new solution B which will consist of subset of projects of solution A. I start by adding the first pre-existing project into this new solution B. This project is referencing couple of class libraries from solution A. Therefore it is logical that these libraries cannot be found and I cannot build. Of course I could add all the referenced projects manually into the new solution B but that would take quite a long time, considering the total amount of projects that I need to add.
Is there some built in Visual Studio feature that can take care of this on my behalf? I.e. I will be offered an opportunity to import all the referenced projects at once and the B.sln file will be updated automatically.
I also have a ReSharper extension but I couldn't find such feature in there as well.
EDIT:
Some more detail on what I am trying to achieve. A.sln has lots of application projects and literally hundreds of class libraries. I want to create a new B.sln for one particular application project from A.sln and only add the class libraries that it is referencing, directly or indirectly... But the dependencies can go up to 15 levels deep so manually removing projects from original A.sln to create B.sln is really not suitable for me as I would have to carefully consider each one of the projects that I would be manually removing from the original sln file, subsequently reviewing the csproj files to find whether the application I am interested in does not indirectly depends on them via one of its direct references.
Copy paste your current solution file and start with it. Open it in new Visual Studio Instance. Remove your projects one by one. Instead of adding new projects, removing unnecessary ones will be more easy for you. As far as I know there is no such feature in Visual Studio as you want.
Removing will be more easy since projects are already there. Do not use Visual Studio to remove project but open sln file in suitable programmers notepad. Your projects are added to sln file as below lines.
Project("{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}") = "Example.Integration.App1", "..\Example.Integration\Example.Integration.App1\Example.Integration.App1.csproj", "{E3977144-AFBA-451D-894C-1F89AA008041}"
EndProject
Removing such lines will be more easy if your projects has naming convention.
The best way to port references from an existing project that I've found is to generate a template for that project.
On the File menu, click Export Template. The Export Template wizard opens.
Choose project template and move through the wizard
Click Finish. Your project is exported into a .zip file and placed in the specified output location, and, if selected, imported into Visual Studio.
Now, when you setup a new project for solution B. You'll be able to choose the project template from A and all the file structure/references are preserved.
Ref: http://msdn.microsoft.com/en-us/library/vstudio/xkh1wxd8%28v=vs.100%29.aspx
We have one master project that creates a single DLL with FEATURE_1, FEATURE_2 and FEATURE_3 as three conditional compilation symbols that enable those respective features.
MyLib.dll => has FEATURE_1, FEATURE_2 and FEATURE_3 compiled in
We now wish to have the same master project spit out 3 different DLLs as follows:
MyLib.1.dll => has only FEATURE_1 compiled in
MyLib.2.dll => has only FEATURE_2 compiled in
MyLib.3.dll => has only FEATURE_3 compiled in
At present we build within VS2013 and those compile constants are defined inside the .csproj file (within the <DefineConstants> </DefineConstants> tags), which hard-codes them.
Is it possible to pass them via a command line so we can still maintain one master csproj but build the 3 different flavors in the RELEASE configuration just by changing the command line (eg: gcc's -D<buildFlag> style) ? The solution has other projects and they're designed to work with the RELEASE configuration. I'm also open to any other technique that is easy to use and maintain.
We're really trying to avoid creating pseudo-projects or affecting other projects in the solution (21 projects in the solution) - seems like an overkill/hackish for something very simple.
I haven't done anything with the command line, but to solve similar problems, I created separate projects (that define the Framework Target and any conditional compilation symbols), and then add all the project files as LINKED files. In this way, I only have to modify a single set of source files, but each project compiles into its own DLL.
To add a file to a project as a linked
Right click the project and click Add Existing Item...
Select the file (or files) you want to Add.
Instead Of clicking the Add button, click the arrow next to the Add button, and click Add as Link.
I'm not sure if this will work for your case, but it sure has saved me lots of time when developing libraries for different .NET framework versions.
Is it possible that you have a complete turnaround?
Instead of defining all features in a single library and then disable some of them, you can create individual projects for each features, and then at packaging phase merge the smaller assemblies into a single one.
Microsoft has ILMerge, while ILRepack is an open source alternative,
https://www.nuget.org/packages/ilmerge
https://www.nuget.org/packages/ILRepack/
Then you are free of conditional compilation, which is too difficult to manage, and the complexity is moved to your packaging scripts, which can be easily managed and checked into source code management.
I have a solution in visual studio where one project (.csproj) is set to create an exe.
I would need to create a duplicate copy of this project so that I can name it something different and change the icon for it. (All of the rest of the projects can stay the same)
I am using conditional compilation symbols for that project, but I don't want to create a whole separate solution configuration because that requires expensive rebuilding of the entire solution.
In Visual Studio under Build -> Configuration Manager, you can create a new configuration for your project and clone it from your release build, then in your project properties you can customize it.
For the icon, you'll want to refer to Set a different ApplicationIcon for each build configuration
Create a copy of the project on disk (outside Visual Studio) and add the copied project to the solution. Then you can modify output assembly name, icon. etc..
However better practice would be to perform the necessary operations as postbuild step (e.g. batch/powershell script) as you will have to keep the projects synchronized (added/renamed/removed files, references...)
Copy it somewhere else and change the assembly name and namespace may be on the project property window( right click and property)
I dont know what your trying to accompish but possible solutions:
add post build event that will copy exe / (exe ad dll-s) to another directory
if you use TFS, edit your Build so it will create copys
Cheerz,