I've a same project that need to be compiled with .NET and Compact .NET Framework.
It is possible to create a C#
compiler that will compile my
project with both framework ?
Some feature aren't present in
CF.NET Framework so I created it by
myself (creating classes having
exactly the same name & options that
in .NET Framework. If I decore this
classes with an attribute like
[CF35] it's possible to parse the
project and :
Use this class when compile the
project using CF.NET
Ignore this class when compile the project using
.NET
?
Thanks for all constructive answers.
[EDIT]
I know the solution that consists to create two projects referencing the same files.
Problem is, you should every time compile both manually.
Moreover, when you add a file to one, you need to open the second and reference it too, that it's just borring to do and according that we are many people to work on the same project, I would like to do this part automatically.
Seems to be possible?
[EDIT 2]
All works fine except ... resources files !
So, to resume, I've three project :
the development project (CF.NET)
the release project (CF.NET 3.5), including all files via ""
the release project (NET 3.5), including all files via ""
As said, all works fine, but now my problem is using Resources files.
What's the method to apply to use it?
When I use the development project, Resource file is correctly retrieved
When I use the two other projects, ResourceManager throws MissingManifestResourceException
Any idea?
You'll need to create different build configurations for each and define a custom flag like USE_CF. Then wrap your custom classes with #if USE_CF and #endif so they get ignored when compiling without that flag
The basic idea would be to decorate your code with #if compiler directives for each framework version?
#if CFNET
// .net CF code
#else
// .net code
#endif
From here one you have two options:
A) 1 project file with custom build configurations
If you would like to have everything in 1 csproj file you'll need to modify it manually. Since this is a msbuild file this is more of a msbuild problem. I figure you would need to do the following things:
Use 2 platform names say "NET" and "CF" (instead of the default Any CPU or x86)
Define CF constant (From now on Edit csproj):
<PropertyGroup Condition="'$(Platform)' == 'CF'">
<DefineConstants>CF</DefineConstants>
</PropertyGroup>
Import correct build targets depending on selected platform:
<Import Condition="'$(Platform)' == 'NET'" Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" />
<Import Condition="'$(Platform)' == 'CF'" Project="$(MSBuildToolsPath)\<CFtargets>.targets" />
I don't know the targets file name of CF since I don't have it installed. It sould be somewhere in C:\Windows\Microsoft.NET\**.targets
B) 2 project files each containing the appropriate build configuration
As I initially pointed out, and also some commenter pointed out, the best solution is to have 2 project files, that you keep in sync. You can have the same source files in both project files.
So an idea would be (instead of copying the file list manually each time) to
think about using T4 templates, to keep the source files in sync (and have 2 solutions, so you wouldn't be prompted to reload the whole solution each time) or to
modify the two csproj files and use a wildcard compile tag like this:
<Compile Include="**/*.cs"/>
There's only one C# compiler, it emits the exact same IL for whatever platform. What's different are the reference assemblies, you have to use the CF versions for the project that targets CF, the desktop versions for the project that targets .NET. Which requires two projects. They can reference the same source code files. Adding CF-only source code files is now of course no longer a problem.
Keeping projects in sync is a feature available in VS2010. Intended for Silverlight, pointless for a CF project of course since it no longer supports it.
a better way is to create your normal project class library (.NET) and add all of your code. Then create your second class library project (.NET CF) but reference the code files from the first project (not copy, but reference). Then you end up with 2 DLL's and you don't have to deal with nasty ugly compiler directives. You get the result you want with no extra work to maintain both projects. Obvisouly you would need to be careful with what you put in the code since .NET CF is limited compared to .NET. I don't know how to add file references (shortcuts) using visual studio but I open the proj file in notepad and use relative paths to the files to include. I've used this method for .NET/.NET CF and also .NET/Silverlight
Also, have a look at Portable Library Tool CTP http://visualstudiogallery.msdn.microsoft.com/b0e0b5e9-e138-410b-ad10-00cb3caf4981/?localeName=ko-kr
Related
I am building a few different C# libraries that both depend on a single C# file we'll call Dep.cs, and these dll's need to be used together in a Unity project. I'd like to set up these projects in the following way:
The C# libraries can be built independently of one another using Visual Studio
C# libraries (i.e. dll's) can be imported into a Unity project without conflicting symbols
The C# library projects (i.e. the source code for each library via git submodule for example) can be imported into a Unity project without conflicting sources.
I've solved (1) by including Dep.cs in each library project that requires it, though this causes issue with (2). And I've solved (3) by putting the dependency in a folder like Dependencies~ so that Unity ignores the file (this way no duplicate classes are found).
I'm having trouble solving (2) however. I thought I'd be able to add Dep.cs as reference in the VS solution but This doesn't seem to work. I've heard of Assembly References but I am not sure if they do what I need.
You can use "Add File as Link" from Visual Studio "Add Existing File" screen. It also works well with git submodule, just place Dep.cs anywhere in a parent folder or in the solution's root directory.
To get the same result you can also directly edit the .csproj file and add a compile instruction:
<ItemGroup>
<Compile Include="..\..\Path\To\YourFile.cs" Link="YourFile.cs" />
</ItemGroup>
This method solves all the issues you mentioned.
To solve my problem I decided to modify the external scripts to be internal this way both dll's can compile with that source and not conflict with one another. The rest of the setup in my question remained the same so this solved (2) for me without compromising (1) and (3).
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've got an C# Project in Visual Studio, which has Console Application as Output Type.
But I also need a Class Library of this project for another solution.
Right now I have to switch the output type every time, but I wonder if it's possible to generate exe and dll at the same build-event?
Is there a post-build-event for this?
To my knowledge there is no possibility to change the output type after compilation. That being said, if would be possible to have two projects like Console and Library in your solution, which would use the same source code files but have different output types. That way you would have different outputs without any duplication of code.
it is generally possible to reference a .net exe assembly as it would be a class-library.
So you can just stick in creating an exe file and reference the exe (sounds strange, but works) in your other project.
This is the dialog for browsing for references. As you see you can select exe files.
But as commented it really depends on what your usecase is.
I don't recommend to ship an exe with an entry point to your customer hoping that the customer does not discover the exe. But what you could do about that is to conditionaly compile your entry point.
For example
class Program {
// This is the entry point of the EXE
public static void Main() {
#if DEBUG
// Start Debug Application
...
#else
// Shipped to client - Entry point disabled
return;
#endif
}
}
If there is a relevant reason to have a shipped exe and a shipped class library, I would refactor your solution like this:
(A) complete application (.sln)
(B) console-application (.csproj) which has a reference to (C)
(C) class library project (.csproj)
With that it is perfectly clear to others that there is an application that uses the library and the library itself.
Console Application is the type of your project. You can not change it.
What you can -and must- do is, carry your logic into a Class Library project and use your class library from any type of project you want.
You should compile your project to become a dll and then use this dll in a console application.
A possibility to achieve what you want is to manually run the msbuild on your post-build event of your project.
See: How do i build a solution programatically in C#?
or Building C# Solution in Release mode using MsBuild.exe
The usual solution for this is using a Solution with two projects:
a Class Library with all the code (which builds into a DLL)
an Console Application referencing the library whose Main just calls some function(s).
For more information, check the MSDN page on Solutions.
Codor suggested manually adding the files to the Console project, but one downside is that build settings are not shared between both versions, so you might get some inconsistency there.
I'm not really sure why people think it's not possible but it actually is.
The easiest way would be renaming the exe to dll Sounds stupid, I know. But it works in many cases. Also, as "Peter I" said a .NET exe can be imported as assembly in other projects. So you might not actually need a dll anyways.
Another way would be using C# command line as stated here: /out (C# Compiler Options)
You can use command command line options in Pre/Post build events Pre-build Event/Post-build Event Command Line Dialog Box
I have a similar requirement and couldn't find any definite answer in this post or anywhere. I currently have a class library and would like to create a console application project without copying any code. Ideally speaking there should be two projects, one for creating a console application and another for creating a class library. And this is what the visual studio also suggests. When I tried to run the class library, I got the below message.
It clearly asks us to add an executable project to the solution and add the reference to the library project.
Below are the steps to do this.
Right click solution -> Add new project -> Console App -> choose name -> ok.
Right click on the console project -> add reference -> In reference manager, click on the projects tab and select the other project(In my case this is the class library project, In case it is not listed just click on browse and select the .csproj file) -> ok.
Now to use the classes in the other project, simple do using LibraryProjectNameSpace
There we are. Bingo!!!!
Also as mentioned in the other answers it is not possible to have the same project generate both .exe and .dll. But you can have the same solution generate these two guys by having two projects. In this way there is no need to switch the output of the project every time.
FYI, I use visual studio 2017
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.
When using Visual Stdio 2008, you can make a C++ project build with an internal tool rather than having the IDE invoke MSVC directly. This improves the consistency of builds across platforms if a cross-platform build system is used.
However, I cannot figure out how to do the same as a C# project. It would be possible to simply register it as a native project with C# sources, however, you lose some of the advantages gained through having a C# project. More importantly, it will mean that allowing a project to build both directly and with an external tool (which is sadly necessary) will require two separate projects, rather than merely creating an alternate build configuration to invoke the external tool.
Does anyone know if it's possible to prevent Visual Studio from invoking csc by itself and instead call an external tool?
EDIT: Apparently there has some misunderstanding. The goal here is not to compile anything outside of Visual Studio. Instead, it's to allow Visual Studio to serve as the IDE but not the build system. There is already a (Scons-based) build system capable of compiling the C# and C++ sources, and Visual Studio has been configured to invoke Scons for compilation of C++ projects. I'm trying to configure it so that when you hit the 'Build' button, it will invoke Scons for the C# projects as well as the C++ ones.
Edit: Your question is still answered using MSBuild(if you are simply looking to compile outside the IDE). The IDE(Visual Studios) is simply a "fancy" way of constructing the build files that are built by MSBuild. Visual Studios isn't building the files, it simply is invoking MSBuild which ships with the .NET Framework 2.0 and up which compiles your code based on the project file that you create. If Scons can read and process an MSBuild file then I'm sure you can invoke it to build your project. But considering the fact that C# is a Microsoft language, I think you will be hard-pressed to find a value-add in not using MSBuild since I'd assume both the language and build tool are very tuned to work together. - End Edit
You can use MSBuild to compile your C# project. If you open your .csproj file in a text editor you will see that it is a MSBuild file. If you want to write some C# outside of the IDE you can construct a build file using the .csproj file as a starting point and invoke MSBuild to compile your apps. The IDE is just a way of abstracting the editing of the MSBuild file away for you.
If you are really industrious you can create a set of custom tasks to do things in your custom build process like move files around and versioning. MSBuild Community Tasks are a great example of using custom code to do task for you during MSBuild.
Given all the other answers, what MSBuild does when either VS or MSBuild perform a build can be found in the Targets files that ship with .Net. These can be be found in the FrameWork directory on your system. In my case:
C:\Windows\Microsoft.NET\Framework64\v3.5
Contains Microsoft.Common.targets among others. This file contains the following snippit:
<!--
============================================================
Build
The main build entry point.
============================================================
-->
<PropertyGroup>
<BuildDependsOn>
BeforeBuild;
CoreBuild;
AfterBuild
</BuildDependsOn>
</PropertyGroup>
<Target
Name="Build"
Condition=" '$(_InvalidConfigurationWarning)' != 'true' "
DependsOnTargets="$(BuildDependsOn)"
Outputs="$(TargetPath)"/>
This means that redifining this Target you can make MSBuild an VS do anything you want. The top of the mentioned file contains an important messagge:
Microsoft.Common.targets
WARNING: DO NOT MODIFY this file unless you are knowledgeable about MSBuild and have
created a backup copy. Incorrect changes to this file will make it
impossible to load or build your projects from the command-line or the IDE.
This file defines the steps in the standard build process for .NET projects. It
contains all the steps that are common among the different .NET languages, such as
Visual Basic, C#, and Visual J#.
My suggestion would be to read all you can about MSBuild and it's build file syntax and try redifining the Build target in your project(s). My impression is that after reading up on MSBuild you'll probably find an easier way to meet your requierements. You can find an example of redifining a Target like this in one of the answers of this so question .
Edit:
How to redefine a target?
Redefining is essentially defining the same target 'after' it has been defined. So for instance in your .*proj file(s) define a Build Task after the <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" /> line that imports all targets needed to in this case build a C# project. An example could be
<Target
Name="Build"
Condition=" '$(_InvalidConfigurationWarning)' != 'true' "
DependsOnTargets="BeforeBuild"
Outputs="$(TargetPath)">
<Exec Command="nmake" />
</Target>
I found a question in the same direction here, where it is suggested to edit the registry. I am pretty sure there is no other way to change the compiler used by Visual Studio because there is no trace of csc.exe in any solution, config, csproj file or whatsoever, nor in the Visual Studio 9.0 folder / subfolders within the Program Files dir.
Registry locations can be found in:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components\74ACAA9F1F0087E4882A06A5E18D7D32
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Installer\UserData\S-1-5-18\Components\9055DA7481CC1024CB23A6109FD8FC9B
but those keys may differ dependng on your installation. Conclusion: changing the compiler used by VS seems next to impossible.
Addition: The following MSDN article deals with the same question for an custom C++ compiler, and Ed Dore's answer seems to confirm my theory that there's no way to choose an custom compiler for use within VS.
Under 'Tools' > 'External Tools' you should be able to define an outside tool to do activities for you. The Command should be the path to the executible for your external tool.
Hope this helps some.
You don't have to maintain different project files to build using an external tool. MSBuild is designed to build using the same project files that Visual Studio uses.
Here's an article that describes it.
Customize Your Builds in Visual Studio Using the Standalone MSBuild Tool
It's for VS2005, but should apply to VS2008 as well.
Looking through the answers, it seems clear to me that integrating scons into Visual Studio in a way that is compatible with the debugger and so on is not going to happen...
An option you might to consider, and I understand you don't want to change build systems, but bear with me, is to use a meta-build system, ie 'cmake'. http://www.cmake.org/
Cmake doeesn't actually build the project. What it does is to create build files for you, that you can use to build the project, and on Windows, the build files it creates for you are: Visual Studio project files. You can simply load those directly into your IDE, and compile, and use normally!
CMake is I feel very easy to use, and provides a high level of transparence and maintainability.
The exact same CMakeLists.txt files on linux will causes linux makefiles to be generated.
On mingw, they can generate mingw makefiles.
There are numerous generators available within cmake. The list is here:
http://www.cmake.org/cmake/help/cmake-2-8-docs.html#section_Generators
http://springrts.com is a huge opensource rts game that used to use scons as its cross-platform build system and now uses cmake.
I understand that you don't really want to have to change build systems, so it is a medium to long term solution.
Cmake is in any case one more option, to add to those of using a custom build tool, or using msbuild, or running the scons build from the commandline by hand.
Edit your project file and update the CscToolPath keys to point to the directory containing your tool and add CscToolExe keys that holds the name of the directory:
<PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|.NET 3.5' ">
.
.
.
<CscToolPath>path\to\custom\tool\directory</CscToolPath>
<CscToolExe>exe name</CscToolExe>
.
.
.
</PropertyGroup>
I have not tested this, and the CscToolExe key may cause problems, in which case I would simply rename the external tool executable to "csc.exe".
You can build your solution from the command line like this:
C:\WINDOWS\Microsoft.NET\Framework\v3.5>msbuild.exe "C:\path\Your Solution.sln"