You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Put all Avalonia package references in .props files
I would propose that independent of being able to build from source such that you can centrally switch your Avalonia version.
The "root" .props file:
<?xml version="1.0" encoding="utf-8"?>
<Project>
<PropertyGroup>
<AvaloniaVersion>11.0.9</AvaloniaVersion>
</PropertyGroup>
<PropertyGroup>
<BuildAvaloniaFromSource>false</BuildAvaloniaFromSource>
<!-- run (on Windows): subst A: <AvaloniaRootFolder> to make this reference work -->
<AvaloniaRootFolder>A:</AvaloniaRootFolder>
</PropertyGroup>
<PropertyGroup Condition="'$(BuildAvaloniaFromSource)' == 'true'">
<IncludeAvaloniaGenerators>true</IncludeAvaloniaGenerators>
</PropertyGroup>
</Project>
This specifies the version if Avalonia is consumed from nuget. For building from source there is a single switch BuildAvaloniaFromSource that you will need to set to true. Note that IncludeAvaloniaGenerators must be set to true too, if you want to correctly build from source.
These props are all relative somewhere in my repository. To have the proper folder reference to the local Avalonia repository, the only solution I found, that would be independent of how a developer sets up his folders, is this:
set your Avalonia root folder as an unused drive letter (on Windows)
set that drive letter to your local Avalonia folder using the subst command
In this props file, of course, you could set the actual path on your machine. The problem is, that you cannot use such tricks in you solution file that also must contain the Avalonia projects. Environment variables do not work in sln files.
Note: there are some more props files for other Avalonia packages like DataGrid etc. Of course you could do a single .props if you did not want to distinguish in such detail.
This does the job for the project vs. nuget references. In order to properly build from source and set breakpoints I needed a sln file that contains the necessary Avalonia projects. This took me a while to get right for a clean build. But its seems that these assemblies are good enough to go:
Note that the project reference are done using the substituted drive letter from above:
The way I am doing this in your mono repo, is to define one such solution with the Avalonia projects and our apps and libraries. Maintaining this solution over time will require regular changes and I only want to do that in a single solution file.
The overall sln then looks like this:
The project just imports the .props file. I also linked the .props files into the solution to allow for easier changes. You can then just normally run the app settings <BuildAvaloniaFromSource>false</BuildAvaloniaFromSource> or running it from source with true.
Please note there are of course workloads that you must install to build Avalonia. This solution is limited to desktop. So other than a specific .net SDK (7.0.404 at the time of this post) that is not so hard to do.
reacted with thumbs up emoji reacted with thumbs down emoji reacted with laugh emoji reacted with hooray emoji reacted with confused emoji reacted with heart emoji reacted with rocket emoji reacted with eyes emoji
-
In some edge cases I wanted to run my Avalonia application such that I can:
@kekekeks gave an example how to be able to debug Avalonia code using a local package: #14446 (comment)
I however wanted to have a pure code only solution. I came up with this proposal here that works for me: https://github.com/llfab/Samples/tree/main/AvaloniaAnimationTest
These are the principles:
Put all Avalonia package references in .props files
I would propose that independent of being able to build from source such that you can centrally switch your Avalonia version.
The "root" .props file:
This specifies the version if Avalonia is consumed from nuget. For building from source there is a single switch
BuildAvaloniaFromSource
that you will need to set to true. Note thatIncludeAvaloniaGenerators
must be set to true too, if you want to correctly build from source.These props are all relative somewhere in my repository. To have the proper folder reference to the local Avalonia repository, the only solution I found, that would be independent of how a developer sets up his folders, is this:
subst
commandIn this props file, of course, you could set the actual path on your machine. The problem is, that you cannot use such tricks in you solution file that also must contain the Avalonia projects. Environment variables do not work in sln files.
The .props file for libraries consuming Avalonia:
So, dependent on the root switch we consume either the nuget packages or the project references defined in the Avalonia props files
The .props file for apps consuming Avalonia:
Note: there are some more props files for other Avalonia packages like
DataGrid
etc. Of course you could do a single .props if you did not want to distinguish in such detail.This does the job for the project vs. nuget references. In order to properly build from source and set breakpoints I needed a sln file that contains the necessary Avalonia projects. This took me a while to get right for a clean build. But its seems that these assemblies are good enough to go:
Note that the project reference are done using the substituted drive letter from above:
The way I am doing this in your mono repo, is to define one such solution with the Avalonia projects and our apps and libraries. Maintaining this solution over time will require regular changes and I only want to do that in a single solution file.
The overall sln then looks like this:
The project just imports the .props file. I also linked the .props files into the solution to allow for easier changes. You can then just normally run the app settings
<BuildAvaloniaFromSource>false</BuildAvaloniaFromSource>
or running it from source withtrue
.Please note there are of course workloads that you must install to build Avalonia. This solution is limited to desktop. So other than a specific .net SDK (7.0.404 at the time of this post) that is not so hard to do.
Hope this helps.
Beta Was this translation helpful? Give feedback.
All reactions