I'm working on a cross-platform application using the Uno Platform.
The app consists of 5 standard head projects for my App and a dozen of referenced cross-platform libraries projects (Uno-platform cross-platform library projects, MSBuild.Sdk.Extras, VStudio 2019).
Referenced project libraries have multi-target frameworks specified like: netstandard2.0;xamarinios10;xamarinmac20;MonoAndroid90;monoandroid10.0.
Solution structure looks like this:
- SolutionApp
- App.Droid
- App.iOS
- App.macOS
- App.UWP
- App.Wasm
- App.Shared
- MultiTargetLibrary1
...
- MultiTargetLibraryN
The problem is that each time I rebuild any of the head app projects, VStudio rebuilds referenced projects for all the target frameworks available.
How to avoid a compilation of unnecessary target platforms?
How can a referenced project get which head project has triggered a build?
Is there any possibility to pass which exact target framework is needed in referenced project building from VStudio?
Example: I choose to rebuild App.iOS and it triggered a rebuild of referenced projects. I want projects with only 'xamarinios10' TargetFramework to be built.
If there are only a few target frameworks or projects compilation isn't slow, but with an increasing amount of referenced projects time extremely grows.
As I've got from msbuild reference: VStudio calls msbuild for each project on solution separately, so msbuild doesn't know which head project has triggered the build of the referenced project and which target platform is required.
This is a known Visual Studio 2019 issue, where all targets are built regardless of the actual head project being compiled.
In the meantime, you can manually exclude some target frameworks when building the application, and use the solution filter feature of Visual Studio so that nuget does not complain about invalid project references. That way, you can make 4 filters, with each excluding the projects that are not used for the platform you're currently working on.
Related
I'm using Windows 10 Pro, Visual Studio 2022 and cmake version 3.26.0-rc3. In my Visual Studio solution I have a static library project, let's call it MyLib, which uses features from libxml2 i.e. it needs to link against libxml2.lib. Also in my solution there is an executable project, let's call it MyExe, which links against MyLib and also has libxml2.lib listed as a dependency in its project settings.
The problem is that in the CMakeLists.txt file of MyLib, target_link_directories and target_link_libraries do not seem to have any impact on the MyLib project settings, particularly Additional Library Directories and Additional Dependencies, respectively. For MyExe, those commands work as expected. If I fix the linker options for MyLib project settings manually in Visual Studio IDE, everything builds fine, but I don't think I should need to manually alter project settings initially created by CMake. So is there something I'm missing here - like that dependencies for a static library project need to be set in a different way in CMake - or is this a bug in CMake or Visual Studio? Are there any alternative ways to achieve the desired behavior and get the build to work?
In trying to find solutions for this I came across this very old post, but if I understood correctly it suggested adding an extra library project which sounds like a huge overkill for a simple thing like this which could be worked around by setting the project settings manually in Visual Studio IDE, so it's not an acceptable solution for me.
Using Visual Studio 2015 Enterprise on Windows 10 64-bit. Working with a solution which contains a bunch of C# library projects.
When building the solution, then building it again, then repeating this, each time there are a handful of projects which build every time. There have been no changes to any of the source files, yet VS still wants to build these projects.
Anyone have any tips on debugging the build dependencies to figure out WHY it wants to build these projects each time?
in project.json files we have a dependencies section and then we also have a frameworks section where under each framework there can be more dependencies.
I'm confused about why sometimes dependencies need to go in the framework sections and other times in the main dependencies section?
for example in several of my projects I have dependencies under dnxcore50 but when I upgrade them from nuget it puts the upgraded version in the main dependencies section and leaves the old one with a lower version under the frameworks section.
In general I'm finding it is very easy to make mistakes and get weird dependency resolution errors in VS 2015 for one framework or another and it is difficult figuring out what caused the error. I've had times where I add a dependency in one project and that causes errors in another project with types found in more than one package in the chain or problems resolving basic primitive types.
It seems like VS 2015 templates may put them in different places vs when you add a reference with nuget, or maybe because I'm using beta5 the tooling in VS is a little out of sync.
Is there any guidance for when to put dependencies in the main dependencies section vs under the framework specific sections?
The reason why you can do framework specific dependencies is that some packages don't support all the frameworks.
The most common case are the NuGet packages that don't support CoreCLR (yet). Some prefer to use alternatives on that framework rather than not supporting it. Therefore, on desktop CLR (dnx451), they use one NuGet package, while on CoreCLR they use another one.
A concrete example for that is in dnu. While running on desktop CLR it uses System.Net.Http. However, on CoreCLR it uses Microsoft.Net.Http.Client: https://github.com/aspnet/dnx/blob/dev/src/Microsoft.Framework.PackageManager/project.json#L29
You might also notice in the file above that we use dependencies and frameworkAssemblies. That's another reason why you would use different packages from different targets. frameworkAssemblies come from the GAC and it only works for desktop CLR.
Therefore, the rule is: use the top level dependencies property when you have packages that will be used by all frameworks that you package supports.
I have a project which builds a DLL (I'll call it mylibrary.dll). DocumentFormat.OpenXml is used by several classes in mylibrary and therefore is a dependency. My project builds successfully and outputs both my mylibrary.dll and a local copy of DocumentFormat.OpenXml.dll. All good so far.
Now I have a new project in a new solution (call it mywebapi). I include references to both mylibrary.dll and DocumentFormat.OpenXml.dll. The project builds successfully and everything is fine.
Here's the trouble, in my project settings, if I have Visual Studio check for "Unused References..." it is telling me that DocumentFormat.OpenXml.dll is not used and should therefore be removed. But if I do not include it in my release, the classes referencing it fail cause the dll is missing.
Is it possible to mark it as a chained reference? Or somehow otherwise tell Visual Studio that it is a dependency?
This is an old question. Never found a solution. But this is probably irrelevant now with newer versions of VS.
I am trying to use MSBuild to compile a solution with a few BizTalk 2010 projects (maps, schemas, pipelines) and a few non-BizTalk projects (console app, web app).
MSBuild gets triggered by Nant. The problem is that, everytime I run the compilation, the BizTalk projects get recompiled (and the assembly version number changes). This happens even if there are absolutely no changes to any part of the entire solution.
In other words, If I build the solution once, the assemblies get created fine. Immediately, if I build again, the non-BizTalk assemblies do not get re-created (MSBuild reports Skipping target "CoreCompile" because all output files are up-to-date with respect to the input files). But, the BizTalk assemblies happily get re-created. This is annoying.
Please can someone help/advise?
BizTalk Server 2009 and 2010 .btproj project files are, indeed, MSBuild projects. As you have noticed, the way standard BizTalk targets are authored prevents incremental build of BizTalk projects.
Fortunately, MSBuild is extensible and can be customized in many ways. Please, follow the instructions on this post to to alter the standard build logic of .btproj files in order to add incremental support for your build system.