Topic: State of tooling

[cwe1ss]

I'd love to have a discussion someday about the state/vision of tooling and documentation around it. It's currently very complicated to setup CI scripts because there are quite a few bugs and cases that are not yet supported properly.

Some examples:

• VS2017 Build Tools don't play well with .NET Core Sdks: Tracking: .NET Core Sdk in Build Tools Installer msbuild#1697
• Restoring packages in "mixed" environments (e.g. Service Fabric) is weird because you need nuget restore and dotnet restore: https://github.com/dotnet/cli/issues/6029 (currently even a "won't-fix")
• Service Fabric doesn't yet support non-web .NET core projects: Using MSBuild to package Service Fabric app including .NET Core projects fails microsoft/service-fabric-issues#152
• dotnet build is slow, slow, slow.
• dotnet pack doesn't work properly with version-suffix: dotnet pack - version suffix missing from ProjectReference NuGet/Home#4337
• dotnet publish removed the --no-build switch: https://github.com/dotnet/cli/issues/5331

It seems like whenever I try to change my script, I run into a new problem. (Luckily, poor people like @NickCraver and @onovotny have already tried the same thing before me so there's already github issues for most of it 😄)

Sure, all of this is (hopefully) being worked on and it will get better over time but I'm not really seeing the "big picture" here on when people should use nuget.exe, msbuild.exe vs dotnet.exe. Now that they all call each other in mysterious ways it's very hard to understand which tool supports what.

My main concern here is that it is very hard to explain all of this to new developers, and it's also a big frustration/confusion point for them.

I'd love to hear your opinions on how this will/should be improved in the future and tackle questions like

• Should dotnet.exe be 'the one to rule them all' and support legacy formats?
• Which project types will move to the new project format and when? (e.g. Service Fabric)
• etc.

[hughbe]

I should preface this with the fact that my interest in .NET core is more from a contribution point of view, although my experience with .NET core helped me land a job working with it in a web app - so I feel your pain.

That said, it's my understanding that this is a standup for corefx, not really for the whole .NET stack (ASP.NET/cli). For me personally, and unfortunately I'm not going to be able to participate in the first standup, I'd like to see discussion about corefx specific things like how to improve contribution experience and future plans including the new networking stack.

TL;DR it's a corefx standup - from the perspective of a contributor, the most value is in corefx/BCL specific things.

[cwe1ss]

the readme currently says under "goals":

Give them space to ask questions about anything involving our .NET Core repos, .NET Core product and .NET Framework.

@karelz Feel free to close this issue, if it doesn't fit this repo.

[hughbe]

the readme currently says under "goals":

Oh fair enough then - don't close this too quickly, it's worth discussion

[clairernovotny]

I'll say that Item 1 on your list, dotnet/msbuild#1697, is better with 15.3 because 15.3 will use the SDK installed by the .NET Core tools and no longer relies on an internal version of it.

That means you have to install the .NET Core 2 tooling separately, but it also means you can use a later version in both the CLI and VS simply by installing it -- which is great. I was able to use AppVeyor's 15.3 Preview 2 image, that only has the .NET Core 2 preview 1 tools baked in, and start using the Preview 2 tooling:

https://github.com/paulcbetts/refit/blob/273f435227d2254ce6ba658f424592850875f642/appveyor.yml#L7-L9

That works the same now whether it's dotnet build or msbuild /t:build.

[karelz]

Discussing larger product issues is not main goal of the standup - it is more targeted at contributor experience in CoreFX repo.
However, we are happy to listen to any feedback and I will personally try to route any feedback to the right place. Contributors (like MVPs) are people who are invested in the technology and IMO should have some voice in shaping it. That doesn't mean we will do everything someone asks for, but listening to the feedback with some minor discussion should be IMO min-bar. (Disclaimer: This is more my personal opinion and others might have different opinions)

@cwe1ss for your specific bigger-picture question I think it would be best to move the discussion to dotnet/core repo. That is IMO meta enough to handle these kind of questions. @terrajobst what do you think? What is best forum/feedback channel for these questions? We should probably have the discussion in the (public) open (this repo is private) ... thoughts?

[cwe1ss]

@onovotny thank you for the link!

@karelz Sorry, I thought this would be more like live.asp.net (which is AFAIU more of a general-purpose standup for all ASP.NET Core related topics). I'd be happy to create this issue somewhere else if you think it's useful. (We can also just close it if you think it's not)

[karelz]

@cwe1ss no worries, our standup may eventually evolve into deeper product discussion. However, we do not have the right MS people in the room at this moment to cover anything beyond CoreFX repo (e.g. msbuild, CLI, Azure).

However, such discussions are valuable and should not be postponed. That's why having the discussion in the open where we can loop in more folks would be likely better & more efficient (assuming it does not become a complaining place for everything ;)). Makes sense?
I think it ties back to understanding the team structure around CoreFX and other .NET Core end-to-end teams.

Please close it once you move the discussion to dotnet/core (feel free to CC me).

[willdean]

IMO CoreFx should be the reference example of how to develop libraries for .NET Core, and writing libraries (even if they're only for internal consumption) is much of what .NET development is about.

If CoreFx is somehow living with a form of .NET Core library development that doesn't match the outside-world's experience of .NET Core library development, then that should definitely be something which is a concern of CoreFx.

[svick]

@willdean

CoreFX is a special kind of library in many ways (for example, not many libraries are used by the compiler that's used to compile the library). I think it would be impossible to make developing it be just like developing a "normal" .Net Core library. And I'm not sure it makes sense to try to close the gap, especially considering people working on CoreFX could instead spend time actually improving CoreFX (and thus, helping all .Net Core developers).

[terrajobst]

@willdean

IMO CoreFx should be the reference example of how to develop libraries for .NET Core, and writing libraries (even if they're only for internal consumption) is much of what .NET development is about.

I appreciate the sentiment here, but I don't think that's technically feasible. Think about it: CoreFx is the implementation of the stack other projects compile against. We obviously can't build against ourselves and thus have -- by definition -- to use a different build environment from everyone else. Of course, CoreFx will also contain libraries that could be using the same public tools, but it's probably easier for us to have a uniform build environment within CoreFx.

We have, however, talked about having another repo that only contains components that sit on top of .NET Core / .NET Standard. Within that, we could -- and probably want -- to use the public tooling. Other repos, for instance, ASP.NET, is largely following that practice too.

[willdean]

@terrajobst @svick At least some of us have already participated in this discussion I think so we may just rehash things, but I can't pass up an opportunity to argue a bit.

We clearly agree that some (there's perhaps a debate about how much, but it certainly includes some big bits) of CoreFx that does not need the special treatment it currently gets.

I can see that giving these bits of it special treatment even where they don't really need is an effort saving to the CoreFx team, and that's clearly beneficial in some sense, but I think it's a double-lose otherwise:

1. It makes CoreFx more weird to work on for outsiders than is strictly necessary, because the whole toolchain/build process is different even where it doesn't really need to be.
2. It allows the normal outside-world build/test experience to be sub-par because significant potential users (e.g. the CoreFx team) aren't using it in the same way normal people have to.

I feel I've said all this already though and there's no reason why it's going to be better received this time than it was last time so I'll leave it at that (I can always say it again next Monday :-)

[FransBouma]

@willdean @terrajobst @karelz
I think what's lacking at the moment is documentation about the tool chain at the level of an end-user: where the end-user is someone who contributes to CoreFX and thus uses the tool chain as a user. There is documentation but it's scattered around and disconnected, and sometimes outdated or full of holes. This is often the case with internal tooling where you can just walk over to the desk of the person who wrote it, look them in the eyes and say "If you want me to keep getting you coffee, please document that particular feature a bit so I can use it this afternoon!" and they'll likely do it (at least you can try ;)).

But this tooling isn't internal anymore: it's used by anyone who wants to contribute to corefx. If the tool chain was treated as a (gulp) 'product' (as it is, IMHO) it might get proper docs which are usable as an end-user and the tool chain by itself is easier to understand. This also has the side effect that the creators of the tool chain might think a bit deeper into UX of the tool chain.

Of course, over the years enough information will be produced by various people so getting started with contributing to CoreFX will be easier than it is today, but it won't be automatic: anyone who has worked with visual studio integration and the VS SDK knows that if no-one steps up and writes really useful docs, things will still go largely undocumented as the group of people who uses it either know what to do or know someone / a way to ask how to do it. For novices / people who want to start contributing this can be a serious hurdle.

[cwe1ss]

@karelz fyi, I haven't created an issue for this somewhere else and I probably won't do so in the near future. Feel free to close this issue if you don't want to keep it open here.

[karelz]

Closing per last reply - we can reopen if people disagree