These are chat archives for AvaloniaUI/Avalonia

14th
Aug 2017
Shimmy
@weitzhandler
Aug 14 2017 01:00
Hello everyone, I just cloned my forked Avalonia repo in VS 2017, and I'm trying to run the samples/controls project and I'm getting many errors. I installed GTK# on my machine.
What steps do I need to take to enable this project to build properly?
Nikita Tsukanov
@kekekeks
Aug 14 2017 05:02
You also need .NET Core SDK, I think
danwalmsley
@danwalmsley
Aug 14 2017 07:40
@aelij you are about to find out that tab control is totally broken and needs replacing!
Eli Arbel
@aelij
Aug 14 2017 09:07
I actually managed to get it working :) Just replaced the template
Nikita Tsukanov
@kekekeks
Aug 14 2017 09:39

getting errors, saying it cant find Newtonsoft.Json version 6.0.0.0

that's from some weird MSBuild task

No idea why that happens
Matthijs ter Woord
@mterwoord
Aug 14 2017 09:41
that's what i got as well!
missing dll in folder containing the msbuild task
Matthijs ter Woord
@mterwoord
Aug 14 2017 12:21
How can i put single's (floats) in resources?
somehow omnixaml reads it as int/long
Nikita Tsukanov
@kekekeks
Aug 14 2017 13:14
xunit/xunit#1213
I think, we can run our tests on Mono again
Jeremy Koritzinsky
@jkoritzinsky
Aug 14 2017 16:19
.NET Core 2.0 (and related sdk) are released!
Matthijs ter Woord
@mterwoord
Aug 14 2017 16:21
yep
Matthijs ter Woord
@mterwoord
Aug 14 2017 16:52
When I use Classes property for custom styling, does that get added to the control's own slectors? (like Button's Click etc)
sorry, pressed
Matthijs ter Woord
@mterwoord
Aug 14 2017 16:59
yeah, it actually does, but not for the pressed state..
:(
Nikita Tsukanov
@kekekeks
Aug 14 2017 17:06

.NET Core 2.0 (and related sdk) are released!

So now we are waiting for IDE that actually works

Nikita Tsukanov
@kekekeks
Aug 14 2017 17:36
But does it actually work?
Steven Kirk
@grokys
Aug 14 2017 17:41
ha, that is indeed the question
my guess is "no"
Jeremy Koritzinsky
@jkoritzinsky
Aug 14 2017 17:51
When I was using a preview build at work last week it worked great. Wasn't using the Xamarin tooling though
danwalmsley
@danwalmsley
Aug 14 2017 17:55
so does this mean we migrate to netstandard2.0 for everything now?
Jeremy Koritzinsky
@jkoritzinsky
Aug 14 2017 17:56
I'm all for moving everything to netstandard2.0
Nikita Tsukanov
@kekekeks
Aug 14 2017 18:00
Well, moving to netstandard2.0 is an obvious choice
I'm just too scared of potential build issues
Moving from PCL to netstandard took away several days of my life
Basically, if someone volunteers to do that, they'll have my moral support )
danwalmsley
@danwalmsley
Aug 14 2017 18:02
how many projects do we have on pcl?
Nikita Tsukanov
@kekekeks
Aug 14 2017 18:02
None
Today I've tried to migrate one simple solution with 5 projects to netstandard2.0
And failed miserably
Because I couldn't reference netstandard2.0 project from net461 project
Jeremy Koritzinsky
@jkoritzinsky
Aug 14 2017 18:04
I'll take a stab at it. I'm going to try to fix up skia-merge first and get it successfully working before I do the netstandard move.
@kekekeks I think you might still need the NETStandard.NetFramework package
Nikita Tsukanov
@kekekeks
Aug 14 2017 18:04
Yep, I've added it
And then somehow I've got even more errors
So I've decided to roll back to netstandard1.3 and be a happy camper
danwalmsley
@danwalmsley
Aug 14 2017 18:07
I suppose there is only a need where we can make use of new apis?
or are there other advantages?
Jeremy Koritzinsky
@jkoritzinsky
Aug 14 2017 18:07
We can move our RuntimePlatform assemblies into our other assemblies since we will have all of the APIs available.
Nikita Tsukanov
@kekekeks
Aug 14 2017 18:08
Not quite
We still need separate logic for assembly discovery
.NET Core apps have their .deps.json file with everything that's needed to load the app
Jeremy Koritzinsky
@jkoritzinsky
Aug 14 2017 18:09
No we can use the same logic. Those APIs have been ported over to AppDomain IIRC even if they delegate to AppContext
Nikita Tsukanov
@kekekeks
Aug 14 2017 18:09
With desktop .NET assemblies are expected to be in output dir
So logic will be different because of differences in actual assembly locations
We could potentially get away with plain AppDomain.Current.GetAssemblies()
But that's not really the best choice, I think
Jeremy Koritzinsky
@jkoritzinsky
Aug 14 2017 18:10
Why not?
Nikita Tsukanov
@kekekeks
Aug 14 2017 18:11
Something might not be loaded yet
Jeremy Koritzinsky
@jkoritzinsky
Aug 14 2017 18:11
True. I'll explore and see what I can find.
Nikita Tsukanov
@kekekeks
Aug 14 2017 18:11
And we are using GetAssemblies to obtain XmlnsNamespace information
I was thinking about some kind of PostBuild msbuild step
That would gather that info at compile time
In the ideal world we could embed that info into resulting assembly
Jeremy Koritzinsky
@jkoritzinsky
Aug 14 2017 18:12
Another thing to remember is that at publish time, all of the assemblies are in the same folder event for .net core
Nikita Tsukanov
@kekekeks
Aug 14 2017 18:12
And avoid reflection
That, actually, depends
You could publish without -r <runtime> flag
Jeremy Koritzinsky
@jkoritzinsky
Aug 14 2017 18:13
We could always either parse the .deps.json or use another available parser for when a .deps.json is present.
Nikita Tsukanov
@kekekeks
Aug 14 2017 18:13
Then it would produce some kind of "portable" bundle
For now we are parsing deps.json by using AssemblyLoadContext
deps.json is actually easy to parse manually, BTW
danwalmsley
@danwalmsley
Aug 14 2017 18:17
would it still work when the application uses composition?
Nikita Tsukanov
@kekekeks
Aug 14 2017 18:30
Uses what?
danwalmsley
@danwalmsley
Aug 14 2017 18:39
like mef or whatever
Nikita Tsukanov
@kekekeks
Aug 14 2017 18:48
Libraries will still be referenced, I think
But external addins might be an issue
Nikita Tsukanov
@kekekeks
Aug 14 2017 19:14
BTW, I think that the problem with skia-merge branch
Is that we are using .NET Core 1.0.4 SDK
It might go away with .NET Core 2.0 SDK
Jeremy Koritzinsky
@jkoritzinsky
Aug 14 2017 19:20
I'm working on skia-merge right now.
The bug that was causing the most issues is actually still present in the .NET SDK. I just filed an issue for it and am using a workaround.
I have the project building excluding our post-build step for .NET Framework
Nikita Tsukanov
@kekekeks
Aug 14 2017 19:44
I guess it might be better to just put test projects to separate directories
So obj/bin won't interfere
Jeremy Koritzinsky
@jkoritzinsky
Aug 14 2017 19:46
I've figured it out including the copying
I'll commit and push it out once I clean everything up
Btw MSBuild Structured Log Viewer combined with MSBuild 15.3 (binary logs and preprocessing) is a godsend for these build issues.
The native copying wasn't working because the *.nuget.g.targets file wasn't being imported because we changed the BaseIntermediateOutputPath after importing the Sdk. So we basically have to set BaseIntermediateOutputPath before importing the Sdk.
Jeremy Koritzinsky
@jkoritzinsky
Aug 14 2017 19:52
Looks like our ReactiveUI submodule doesn't want to work on AppVeyor now...
@kekekeks any ideas why suddenly our ReactiveUI submodule won't clone correctly on AppVeyor?
Nikita Tsukanov
@kekekeks
Aug 14 2017 20:02
I guess, 3f725c808b1d4c8457f0d3204e0a071aa462cd75 doesn't exist in the referenced repo anymore
We don't have our own fork, right?
reactiveui/ReactiveUI@3f725c8
Yep
Jeremy Koritzinsky
@jkoritzinsky
Aug 14 2017 20:03
Nope. We're just using one of their versions as a submodule. We can always temporarily fork even though we'll chuck it after v8 comes out
Nikita Tsukanov
@kekekeks
Aug 14 2017 20:03
It doesn't exist on any branches
Jeremy Koritzinsky
@jkoritzinsky
Aug 14 2017 20:03
Or we can pick a version tag to work from.
It should allow to grab that revision from our fork now
Jeremy Koritzinsky
@jkoritzinsky
Aug 14 2017 20:06
Do you want to push the submodule update to point to that onto our master or should I?
Nikita Tsukanov
@kekekeks
Aug 14 2017 20:08
go for it
Jeremy Koritzinsky
@jkoritzinsky
Aug 14 2017 20:08
will do