Open cloudRoutine opened 8 years ago
Fantastic job! :clap: Maybe we should state also which key-value pairs are absolutely mandatory?
How to indicate that certain files should only be accessible under a subset of configurations
It just occurred to me that the only times I did something similar I always conditioning the file presence to a compile constant. Maybe we could include something like (name Constraint
is tentative):
Files = [
{ Compile = "src/file.fs", Constraint = "DEBUG" }
]
Which would translate to:
<ItemGroup Condition="$(DefineConstants.Contains('DEBUG'))">
<Compile Include="src/file.fs" />
</ItemGroup>
@cloudRoutine Looks good to me. Nice starting point. Here my 2 cents:
# FSharpCore : string - Version Number of FSharp.Core
Why do we need that? Shouldn't fscore just be another dependency?# Guid : Guid
Why? Shouldn't be the name unique already? ProjectReferences = [ { Name = Arg, Project = "f3d0b372-3af7-49d9-98ed-5a78e9416098", Private = true }, ]
Ok no I understand Guid from above, but wouldn't Name work as well here? If not we should at least give it a better name as Guid's are used for a lot of things (msbuild uses them for project-type for example)....[ 'netcore'.1.6'.Release ]
You probably meant [ 'netstandard'.1.6'.Release ]
or [ 'netcoreapp'.1.0'.Release ]
. Correct?fable
? I'm ok with figuring this out along the way...FSharpCore and Guid are msbuild properties, the way this is going to work for a while is the toml file is going to be used to generate an fsproj. Also the FSharpCore property is what determines how the IDE checks against the src file. In the project I have open in the screenshot I have the core version set to 4.1 while the actual core dll I'm referencing is 4.0, the IDE treats it like 4.1 as you can see from the struct record
ProjectReferences only have guids that refer to the project's unique identifier. The projecttype guids are a small set of guids that are pretty easy to recognize once you're familiar with them. also they're not a necessary property, the project's guid is.
yea it's a typo
Framework Ids : net | netStandard | netcoreapp
the actual framework ids are up there
There would not be a new target framework specifier for Fable, there's no reason for there to be one for it either. Those are for .net
We can't make projectreferences like normal references, the way they work and are processed are totally different. If you look inside a solution file you can see that the projects are referenced only by their guids, like so -
GlobalSection(NestedProjects) = preSolution
{83F16175-43B1-4C90-A1EE-8E351C33435D} = {A6A6AF7D-D6E3-442D-9B1E-58CC91879BE1}
{8E6D5255-776D-4B61-85F9-73C37AA1FB9A} = {A6A6AF7D-D6E3-442D-9B1E-58CC91879BE1}
{B8B3F011-54F3-43D3-BC94-3ECBE5A3770C} = {ED8079DD-2B06-4030-9F0F-DC548F98E1C4}
EndGlobalSection
A reference without a hintpath is always resolved from the GAC
We're not trying to create a totally new project system whole cloth. This is a slimmed down, more easily usable, declarative subset of msbuild that contains just the data that FCS and FSC need.
FSharpCore and Guid are msbuild properties, the way this is going to work for a while is the toml file is going to be used to generate an fsproj. Also the FSharpCore property is what determines how the IDE checks against the src file.
So it's a complete implementation detail and should be figured out automatically in the fsproj
generation process (by looking at the actual FSharp.Core reference)?
A reference without a hintpath is always resolved from the GAC
Yeah I never liked that anyway. I saw situations where this lead to really really hard to find errors...
We're not trying to create a totally new project system whole cloth. This is a slimmed down, more easily usable, declarative subset of msbuild that contains just the data that FCS and FSC need.
Ok :)
it can't always be figured out automatically because the fsharp.core reference can be defined as such
<Reference Include="FSharp.Core, Version=$(TargetFSharpCoreVersion), Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a">
<Private>True</Private>
</Reference>
or in toml form (something like)
References = [
{ Include = "FSharp.Core", Version = %(FSharpCore), CopyLocal = 'Always' },
]
Yeah I never liked that anyway. I saw situations where this lead to really really hard to find errors...
Well with netcore you'll never have that issue again :stuck_out_tongue_winking_eye:
Open Questions