I have a .NET class library project that targets UWP applications. I wish to re-purpose it to also support Xamarin.Forms applications.
Initially, I imagined that I could achieve this by creating a new .csproj file, in the same directory as the original, and configure it to reference the same set of source files, but with a different set of dependencies, as appropriate to the target framework.
However, this doesn't seem possible, since each of the projects expects its dependencies to be defined in a project.json file that resides in the project directory. If it were permissible to rename project.json to a framework-specific name, that would solve the problem. But, as far as I can see, the name and the location of project.json is fixed.
Is there a recommended way of creating multiple projects that reference the same codebase, but with different dependencies?
Related
I have a set of utility classes that I reuse in several xcode projects.
I want to include the utility classes in every project.
I currently do this by adding inside every xcode project a group and dropping there the files from the file system.
This way, they are included in the compilation.
But every time I do filename changes in the utility classes (e.g. add/rename/delete a file) I have to go through all the projects and reflect the change there.
Some notes:
The projects are irrelevant, i.e. not different products from a suite of products. So I cannot use an all products project and do the separation at the targets level for each of the products.
When I do changes in a utility class from one of the projects, the changes should be reflected in all other projects.
the utility classes are already on a repo of their own.
I prefer not to make copies of the files of the utility classes inside every project
I do not want to do the trip of creating a framework that will then be used by every project. Not all classes are used by every project. I just want to have them compiled as a source files.
As a test, I made a project containing the utility classes and no target, added the project as a child of one of my projects.
I.e. instead of having the yellow folder icon of the file group, I have a project icon containing the files.
The compilation does not seem to pick these files.
Maybe a cmakelists.txt file could serve this purpose? I.e. give to xcode an additional list of files to include in the compilation?
For the Windows's edition of my projects, I use Microsoft's Visual Studio "shared items" project which accomplishes exactly all these requirements.
What is your advice for xcode?
Thanks!
Similar to:
Sharing classes between projects in xcode/objective-c
Sharing classes between Xcode projects
I have a project that is referenced by many dependent projects, and some files in that project that must be in the binary directory of the dependent projects for the dependent projects to run.
Currently, I have several custom AfterBuild targets defined: one in the referenced project to copy the necessary files to a shared location, and then one in each of the dependent projects to reach out and copy the files from the shared location to their bin directories. This works, but it's annoying to maintain and it feels brittle and hacky.
What I would like to achieve is to get my files worked into the primary project outputs for the referenced project (i.e. alongside the .dll and .pdb), such that the files are automatically copied to the dependent projects' output directories at build time via the MSBuild ProjectReference.
Is this possible? If so, what is the mechanism by which primary outputs are discovered and to which itemgroups must I add my files? Is MSBuild "hardcoded" to look only for .dll and .pdb?
For reference, I would consider myself somewhere above an MSBuild novice, but far below an MSBuild expert. I've read Hashimi's "Inside the Microsoft Build Engine," understood it mostly, and I've been able to dig through the MS targets files a couple of times for other tasks, with moderate success. This problem is beyond me so far, though.
Also, I have reviewed this similar-looking question, but it doesn't address project references; only producing additional files with a project.
I have an executable, which supports two rendering backends (GL and D3D), each implemented in a separate static library. I have project configurations permuted on the debug-level (eg. Debug, Release, etc), and the renderer, so the final configurations are (Debug_GL, Debug_D3D, etc.). In my previous question, I learned how to make per-configuration dependencies.
My problem now is that I also have additional static libraries, which are not dependent on the renderer type. When I create the (CMake) project configurations above by setting CMAKE_CONFIGURATION_TYPES, these static library projects also get configurations permuted by the renderer type. I do not want this, because those configurations have separate object/library directories, etc., but they are essentially duplicates.
My main focus is generating for Visual Studio, so ideally the generated solution along with the renderer backend libraries would have the full set of permutations, whereas the non-renderer specific libraries would only have the 'debug-level' configurations. Is this somehow possible with CMake?
Configuration set is global for whole project. Each configuration is built in its own directory. E.g., from the description of LIBRARY_OUTPUT_DIRECTORY property:
This property specifies the directory into which library target files should be built. Multi-configuration generators (VS, Xcode) append a per-configuration subdirectory to the specified directory.
In other words, any target (e.g., library) built within project cannot be shared between different configurations.
If you want some targets have their own configuration set, you should move them into another project. Disadvantage of this approach is that it is difficult to make one project being automatically rebuilt while sources for another project are changed.
I have a solution wich consists of main application MainProject and several plugin projects Plugin1, Plugin2 etc. Each of them is build in a separate project within Visual Studio.
For building the soution, I want all files of the plugins to be copied into the main application's output directory. But I don't want MainProject.exe to contain explicit references to the plugin dlls (they are loaded dynamically). Therefore defining project references for MainProjectdoesn't work.
I could use a post-build-step copying the files "manually" (as described in C# - Copy dlls to the exe output directory when using dependency injection with no references?), but since there might be multiple files for each plugin and they also change from time to time this solution is rather tedious to maintain (especially since I do have different build configurations, each of them producing different files). Also I would like to easily select, which plugins should be copied for a certain build.
What would be the best way, possibly involving custom MSBuild configuration changes, to do this?
See this link: http://msdn.microsoft.com/en-us/library/bb629394%28v=vs.100%29.aspx
When invoking MSBuild on the main project, if you could pass something on the lines of:
msbuild /p:CustomBeforeMicrosoftCommonTargets=[your custom msbuild file];PluginList=PathToPlugin1.csproj,PathToPlugin2.csproj
In your custom msbuild file, a target such as GatherInfo will get you the paths to output files of each plugin project. See this question for a sample: https://stackoverflow.com/questions/23346782/how-to-identify-files-needed-to-build-a-wix-project
I'm using Castle Windsor to do some dependency injection, specifically I've abstracted the DAL layer to interfaces that are now being loaded by DI.
Once the project is developed & deployed all the .bin files will be in the same location, but for while I'm developing in Visual Studio, the only ways I can see of getting the dependency injected project's .bin file into the startup project's bin folder is to either have a post-build event that copies it in, or to put in a manual reference to the DAL project to pull the file in.
I'm not totally thrilled with either solution, so I was wondering if there was a 'standard' way of solving this problem?
Could you set the build output path of the concrete DAL project to be the bin folder of the dependent project?
Mike: Didn't think of that, that could work, have to remember to turn off copy-local for any libraries / projects that are common between them