After spending time in the recent years working more in JavaScript and TypeScript both client side and with Node I've developed a deep appreciation for the simplicity of the model where the same language can be used for builds and application code. In the Node world it takes no effort to convince developers to tinker and explore the build process and I believe that's why there is such an explosion of mature and highly ergonomic process related projects on NPM.
Ultimately what I think is needed is for Visual Studio and perhaps MSBuild to make it easier to accept alternative build commands. I think VS Code is doing a great job on this front but there are still pain points that I think are mostly related to the gravity Visual Studio and MSBuild. An example would be with the current state of F# development. The editing experience for F# in VS alright but Go to Definition and features like that don't work correctly between csproj and fsproj based projects and even in VS Code with Ionide, a fsproj file is needed to get intellisense. So far I can't find any reference to how to latest announced tooling changes affect F# projects with regard to wildcard file includes and PackageReference elements. All while I'd be happy to completely ditch fsproj for a solution like FAKE as long as fellow Visual Studio developers could still develop on the project with proper intellisense support that they would expect.
My mine gripes with MSBuild and csproj files in general is just that it feels like a technology like SQL where it's just stick in the past and seems that there is no hope in any real meaningful change. Maybe this will change now but after years of making suggestions to improve things like project relative pathing for dependencies, nuget package reference redundancy, non alpha item ordering, complex file pairing (ex. xsd, cs, code behind, designer.cs), lack of wild card support, and an overly complex extensibility story I've gotten the same feeling that I ended up getting with WebForms, then Silverlight, and then WPF that nobody on the other side really cared about moving things forward anymore and just about maintaining what was already there.
I think the suggestion of creating a clean object model around projects or a set of APIs of sorts that Visual Studio would use to read and understand a project, modify it, and ultimately build it would be great. If it could be kept in a way that could be extensible to allow for other project formats then great. If those formats were not restricted to different serialization flavors of the same object model but instead allow for alternative build implementations such as CAKE, FAKE, or something homegrown to be plugged in then that would be excellent. For those who have worked in Node.js I'd like something as ubiquitous, simple, and powerful as npm scripts so that any project can be built not by calling msbuild necessarily but by invoking the default build for that project which may or may not be MSBuild.

Just like there wasn't any need to provide super awesome editing experience for .net config files for years and years.

Yeah... speaking of which.  That is another tech that continues to suffer from the same fundamental problem we are discussing here: XML-based mapped DOM (weak/no schema) vs. POCO-based serialization (strong schema).

I mean, editing that thing isn't rocket science :p

Haha... wanna bet? 😛  Especially compared with modern experiences and ESPECIALLY compared with existing editing experiences in Visual Studio with Xaml (which is what I keep going back to as the ideal model here).
I know you don't think this is a big deal @kzu as you obviously have a great handle on this, having creating what I feel are some of the best formatted/created MSBuild files I have ever personally seen (look at those beauties! Just you look at them!!!).  Wouldn't it be great if everyone were so great and fluent with MSBuild?  That's ultimately what we're after here.

If people cared that much, they should probably get on to "fixing" that already.

That's what we're trying to do here. :)  However, as discussed above the current model is entrenched in the XML API and is nearly impossible to modify without mass, sweeping (and certainly breaking) changes.  So until we get buy-in from the project holders here to reflect the will/desire of the community at large, the best course of action we have here is to talk about it in hopes that they do. 👼

Oh god. I just finished reading this.
Need more coffee.

 Very sad!

on behalf of Trump.

Some people just want to keep things complex. No, they are not - I've been using MSBuild extensively in the past years but try to convince someone else from my office - you'll utterly fail because:

It's way more complex than needed. It's a camel with a giant laser tied to its back - very extensible but who needs that?!
Not readable.
You really need a build engineer to get an advanced job done properly. Don't you guys think this should be done by devs without investing too much time?
You're expecting people NOT to touch .csproj files (look at VS tutorials for editing .csproj). Hence the camel thing. It's supposed to carry you on, but when it doesn't - use this laser to help yourself throughout the desert.
I mentored a couple of interns straight into .NET Core since we're heavily using it in our organization. Yesterday I had to ask them to migrate to and take a look at MSBuild ( consider they were taught to add/remove packages and do changes straight into project.json. No UI stuff.). You don't really want to know their reactions.

Tl;Dr: I'm not just for json syntax. I'm all-in for making things simple. This philosophy of "It just works, but when it doesn't - buy yourself a book". It's not working good.

+1

Haha @YehudahA you can upvote the issue up top at the root comment.  That is what matters here.  Otherwise, you are bound to get the downvote as @MartinJohns has so aptly and deftly demonstrated. 😄
Speaking of upvotes, this issue now stands at 103, plus 9 hearts now.  For context, the closest issues for either category are 9 upvotes, and 1 heart, respectively.
I also want to send a shoutout to @gulshan's great suggestion at https://github.com/Microsoft/msbuild/issues/1289.  Please take a second and provide feedback and/or an upvote there, too.
Thank you everyone for your continued support and dialogue towards improving MSBuild, and making it the authoritative build solution we all would like to see and use. 👍

Please... no more " is evil and need to be rewritten from scratch".
I've only spent a year in the GitHub repos and I can't stand it anymore (until my next coffee probably).
No technology is perfect. If  was perfect, everyone would be using it. It's always a matter of compromise and historical context. So in the mid time, if you think that  is so bad that it needs to be rewritten... create a new  and add yourself to the list bellow.
: Swap in your favorite technology. Works for .NET Core, MSBUILD, JavaScript, Java, Erlang, your rewrite of

Having a badly formatted csproj with MSBuild is just... horrible! What was wrong with having project.json that was used by the dotnet tools like publish?? Using XML to begin with is retarded for something that should be human readable (yes, project files SHOULD be human readable!).

@Grinderofl Let me poor some good diesel on the flames.
MSBuild is the standard project system for the WHOLE ecosystem right now. Microsoft has a finite amount of developers working on each technology/stack. If they split the project system in two, they now have 2 teams driving efforts to improve the build system in two different ways.
But that's not all! Now your customers are pissed because now you have two build systems and they have to learn another one.
 So unless they are creating the future of Build System, going back to MSBuild is actually a pretty sensible idea. project.json was created when DNX was invented. The focus was not the build system but rather... throw ideas at the wall and see what sticks.
If they kept project.json, they would have ended up with the situation I described above. Pissed off customers and unfocused efforts on two systems instead of one.

They don't have unlimited money, time and customer patience any more than the rest of us do. This is open source though- if you really want to make this happen, it would be better to present a comprehensive design plan that includes a unified build system between all .NET project types (heck, C++ projects too or it won't be useful for my solutions), and actually write a proof-on-concept showing why this has only advantages over the msbuild system.
I would love that, because you guys do have some cool concepts. However, doing that work is different than sitting around and sending the message, "Microsoft, give us stuff, figure out the hard parts for us, and do all the implementation, and change the way all your customers work."

@jnm2 You forgot about the "but even after you did all this, we'll reject your solution anyway." 😉

Having a badly formatted csproj with MSBuild is just... horrible! What was wrong with having project.json that was used by the dotnet tools like publish?? Using XML to begin with is [..] for something that should be human readable (yes, project files SHOULD be human readable!).

Having a badly formatted project.json is just as horrible. Did you take a look at the new cleaned up csproj file? While there are still things I'd like changed (e.g. Version as an attribute instead of an element), I think it's a lot more clean and lean.
And honestly, XML is just as human readable and human editable as JSON is. I agree that project files should be human readable - and that's what the MSBuild project files are.
And the project.json had other drawbacks too (no way to comment, no trailing commas).
While the "Format Agnostic" approach is probably the most flexible solution, I don't think it's very feasible. It would lead to fracturing the eco-system even more with doubtful benefit and it would increase the complexity of the whole system enormously. "How do you do XYZ?" - "Well, that depends on which of the 50 build systems you use!"
Staying unified on the MSBuild system is the best choice they can make. And frankly, it's really not as awful as a lot of vocal voices want to make it appear to. Especially with the clean-up process Microsoft is doing.

@MartinJohns I hope you can appreciate the irony as I do of having you declare that there will be 50 flavors of build systems and then state it's never as bad as people make it out to be. 🎆
To be sure here, the idea is to have one CLR-based model that can be described in numerous formats.
Also, I am starting to edge up to @jnm2's challenge here of writing a very simple proof of concept to demonstrate the idea.  With as much energy as I have already spent in this repo, I feel like I could have done it in spades times ten now. 😛   I do not want to spend too much time with it for the reason @MaximRouiller states (and more).  Let's see where the afternoon gets me (what did I just get myself into now???).

@MartinJohns

While there are still things I'd like changed (e.g. Version as an attribute instead of an element)

This is happening.  You can see here where we are updating the VS project templates to take advantage of this: dotnet/sdk#394  We are also working on further cleanup of the .csproj format.
To @Mike-EEE and others who want to experiment with supporting an entirely different project file format in MSBuild, the place to start looking is probably in the MSBuild Construction APIs.  These abstract the underlying XML representation to some degree.  They do still reflect the underlying structure of the XML though, so you still have properties inside of PropertyGroups and items inside of ItemGroups, for example.

Thank you @dsplaisted for the pointer.  We actually found that out earlier in this (now rather lengthy!) thread, when discussing the feasibility of using POCOs vs. XML.  XML is indeed tightly coupled to classes throughout the MSBuild libraries, even being used as full properties such as the Project.Xml.
(Can you imagine a Project.Json property?  Data should not be tightly coupled to the serialized object it describes.  That is what we are aiming to solve.)
To underline the ask here, the idea would be to not introduce a new format, but simply make it so that properties such as Project.Xml go away, and the XML that is read in will simply serialize the Project entity in memory, along with all of its child instances.  Hopefully that makes sense.
Once you have this working for one format (XML), then you can make it work for other formats as well.  In essence, the project file becomes a serialized Project entity and it can be described in any supported format, and in doing so will yield any tooling magic that is already built for said format.

Part of this whole thing is that the knowledge of how to build a C# app is in a .targets file which absolutely needs to work with property groups and item groups. Even if you want to serialize the msbuild project as JSON, you'd need JSON versions of item groups and property groups, or else you'd have to abandon msbuild and the C# .targets and write the entire process from scratch.

OK, I took some time to flesh out a SUUUUUUOOOOOPER rough model in what I am thinking here.  You can find that here:
https://github.com/Mike-EEE/Stash/tree/master/MsftBuild.Model
I've placed the project POCOs here and the processing POCOs here.
I've described a possible project file here and a possible processing file here.  I used @gulshan's template from #1289 as a guide.  That's not to say that I followed it completely, however. 👼
The design that I landed on (and am in no way suggesting, just rough-sketching here) makes the Project file a ServiceLocator, so that its "properties" (or services) are not strongly defined, which makes it super flexible.  It is up to the processor to pull in the data that it needs (as demonstrated here).
(Again, this is not in any way making a final suggestion in any sense.  Just doing some sketching.)
Design discussions/decisions aside, in the end what is important is:

A Project POCO element is defined in a serialized format. (Example)
That Project is then read into memory. (Not defined in this sample)
That Project is then sent to a Processor of some sort. (Example)

I've also described this in Xaml (as you probably know, I am a fan) to also showcase some neat things you could do in this particular format, such as provide a version from an external file, and also use one to query the files needed to compile.
Finally, to showcase the "tooling magic" I keep talking about and the reason I am so Xaml/POCO-crazy, here is a screenshot of the mouse cursor in the minimum logging level of one of the elements:

You can see there's a drop down list, checkboxes, and everything, without having to do anything but simply define a POCO in the Xaml file.  This is truly a "lit-up" experience, IMO.  Furthermore, in Xaml, there is plugin support for the editors used for the property pane, so we could make it even more customizable/cool if we wanted to.  It's this sort of power/paradigm that I think we should strive to achieve -- but in any format possible and not just Xaml.
Hopefully that will clear up my side/position here.  But I am sure this will create more questions than not. 😄

@Mike-EEE Too much noise :) The cleared .csproj is much more readable and human friendly.

Haha @djanosik yes I should have put a disclaimer in there regarding that, as Xaml is definitely more chatty than JSON (or XML).  As I mentioned in #1289, there are new flavors of Xaml emerging that address this issue.
However, what is important here is not the verbosity and/or chattiness, but the features and tooling integration that is possible with a POCO-based approach, which Xaml does a great job of doing and I hope that the screenshot and use of MarkupExtensions capture.
Again, the idea is to eventually capture such concepts and make them available in any format.  I use Xaml as of course it does this out of the box without a lot of effort on my part to demonstrate.  I'm lazy, what can I say. :)

@Mike-EEE my guess is that you'll interest more people with a project.json-like format reader first, then a csproj-format reader, after that write a XAML one. :-D

Haha... OMG I am dying here.  OK.  I went ahead and made you a Project.json file, @jnm2 and @djanosik:
https://github.com/Mike-EEE/Stash/blob/master/MsftBuild.Model/MsftBuild.SampleProject/Project.json
So again:  It's not the chattiness or (theoretical) schema that is used here that is important. What IS important is that this file and this file both describe this POCO.  Make sense?

@Mike-EEE It makes sense. How would you create custom build tasks (preferably without referencing other assemblies)? Or do you want to completely separate project metadata and build script?

Ah now @djanosik you're proving that the reward for hard work is more hard work. :)  In this case, we are tackling a few items here.  This actually started out over @ #1289 when @jnm2 rightly reminded me from a discussion in https://github.com/aspnet/Home/issues/1433 that processing should be separate from data.  So this POC is really showing off two things:

POCO-based modeling
Separation of concerns between processing and data/definition.

Now, to answer your question, creating a new custom build task would be similar to implementing ITask as I have done for the BuildProcessor here.   In this case, the BuildProcessor doesn't have any properties, but if it did, it would be described/defined in the Processor definition file.
Again, this is simply a sketched idea, and nothing definitive/authoritative, to help flesh out the idea of what I am interested in solving.

Reading this thread, it's as if Gradle and HOCON don't exist ... I don't mean that as trolling, just wondering why there is not even a mention of those since truthfully, they are a joy to use. HOCON is already there: http://getakka.net/docs/concepts/hocon. Now waiting for a Gradle plugin for .NET :)

Indeed @slorion, Gradle is very much a driving force behind #1289,  Check it out and make sure you upvote it and/or share your feedback.  I was not familiar with HOCON until you mentioned it here.  Thank you for sharing.  The idea here is to be able to support any format as long as there is a serializer for it.  So if HOCON has serializers, then it will be possible to tie into it as well. :)

Ah thanks, glad there is some push for that idea.
I was mentioning HOCON because I saw some comments about web/app.config which are also a pain to deal with, especially when deploying to multiple targets with some specific configuration.

 And I have use .NET Core from DNX RC1 to .NET Core 1.1. The project.json is big forward step. Were you thinking of our feedback ? And if you (.NET Core MS dev team) are insist to give up project.json, I will give up .NET (Core).

Just as a simple idea, if .Net core needs to switch across to using .csproj files for the IDE
and the only way to make changes to it without the ide is via a tool (which sounds kind of horrible)
Why not have a tool / something part of the dotnet tool that reads in a project.json file and outputs the .csproj file as part of the build process
so instead of project.json.lock which is sort of a postbuild version of project.json, it outputs directly to a .csproj file instead
It's a bit of extra work but it's probably worth while

I don't want to dampen the enthusiasm for further thinking outside the box, but the new .csproj is a brilliant solution so far.

All I see is people arguing about the json format just because they never used it and because it knows msbuild from top to bottom.
<NuGetPack File="%(NSPSTransformed.Identity)" OutputDirectory="$(BuildOutputNuGet)" Properties="Configuration=Release" IncludeReferencedProjects="true" ToolPath="$(nugetToolPath)" />

Anyone is really comparing that 💩  to project.json ?
All I see in every csproj file suggested, posted, and called fabulous intelisense is full of magic strings even for stuff like True and False.
Ironically, feels like CSPROJ is not typed while JSON is typed.
on project.json side:
some smart people realized that this would be a great format for asp.net core. Even Fowler said it was it's favorite feature.
It's not about the format or the intelisense or feature A and B. it's about a whole experience.
It's typed, got intelisense, got http request options, was very fast, very understandable, super ultra duper hyper dicoverable, and if you think csproj also is, you didn't USED it, and just commenting based on looking at the file on some github repo.
If you are going against it, let us know that you used it and tried for a least a week.
but
apparently, it has some limitations that aren't present on csproj. (and this might be a very good/valid reason to drop it's support of right now)
I'm all supportive to the csproj and I trust people behind the product.
Just, give some credit and ask yourselves "why, if project.json is no good than csproj, the smart people behind asp.net invest and make a system that everyone (that used it) fall in love at first sight?"
Imports? Targets? Properties? ToolPath? those words are all meaningless and that's why you don't see it mentioned on project.json at all, while target framework, dependencies, includes (which tooltips suggesting that supports globbing patters, a string or an array of strings inside a publishOptions are very self explanatory.
conclusion: project.json is A-MA-ZING. period. If you don't think it is, you didn't used it. It's not about the file format but for a lot of subtle thing that became with the "experience". Stop comparing it via file diff. just pick a project and start developing.
True fact: When project.json was first introduced, it had no documentation, no answer on stack overflow, no real help from the IDE, still all web developers were editing it by hand and were very happy.
Now in csproj, we have docs, lot of history, a 1.1 stable product, experts around the globe, and yet web developers are using a less-productive GUI to make changes to the project file and aren't any happy with csproj.
To all project.json haters: try it. and point exactly what's flawed or bad about it.
To all msbuild lovers: sorry, there is better stuff out there, even if it means you need to change/adapt.
To all project.json lovers: it has limitations and associated costs. Deal with it, having one thing is best overall, and you can still dream of a better future.
to all msbuild haters: be vocal about your pain points. chances are (at least have some faith) it will evolve to something useful as project.json was, not today... but it might happen.

Proposed a .net object notation format based on object, collection and index initializers here- dotnet/roslyn#16648
Please have a look. I deliberately used a project description for example. 😄

I think @jnm2 is right. As much as I complained about the move back to XML, I can now see that it was a communication problem. The CLI/MsBuild team told us "trust us it will be great" but they didn't provide examples or ever update the docs.
IMHO the new csproj is GREAT. I'm having an easier time with it than with the json syntax honestly.
Here are two (names masked) csproj files i am compiling today (in VS2017 RC3).

I am developing in VSCode and VS2017 interchangeably and at the same time
I am running via F5 (debugging) and from dotnet run.
I am debugging and using Edit+Continue
I am hand editing the project file and VS2017 is updating in realtime.
I am generating platform specific executables via dotnet publish -r win7-x86 at others
Dozens of .cs files, thousands of lines.
No GUIDS
No crazy conditions

Library (MyCorp.Lib.csproj)
<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netstandard1.6</TargetFramework>
  </PropertyGroup>
  <ItemGroup>
    <PackageReference Include="Newtonsoft.Json" Version="9.0.2-beta2" />
    <PackageReference Include="protobuf-net" Version="2.1.0" />
    <PackageReference Include="System.Diagnostics.Process" Version="4.3.0" />
    <PackageReference Include="System.IO.MemoryMappedFiles" Version="4.3.0" />
    <PackageReference Include="System.IO.Pipes" Version="4.3.0" />
    <PackageReference Include="System.Runtime.Loader" Version="4.3.0" />
    <PackageReference Include="System.ServiceProcess.ServiceController" Version="4.3.0" />
    <PackageReference Include="System.Threading.Tasks.Dataflow" Version="4.7.0" />
    <PackageReference Include="System.Threading.Thread" Version="4.3.0" />
  </ItemGroup>
</Project>

Executable (MyCorp.Connector.Runner.csporj)
<Project Sdk="Microsoft.NET.Sdk">
  <PropertyGroup>
    <TargetFramework>netcoreapp1.0</TargetFramework>
    <AssemblyName>MyCorp.Connector.Runner</AssemblyName>
    <OutputType>Exe</OutputType>
  </PropertyGroup>
  <ItemGroup>
    <ProjectReference Include="..\..\Lib\MyCorp.Lib.csproj" />
    <ProjectReference Include="..\..\WebStuff\MyCorp.WebStuff.csproj" />
    <ProjectReference Include="..\..\Connector.Common\MyCorp.Connector.Common.csproj" />
  </ItemGroup>
  <ItemGroup>
    <PackageReference Include="protobuf-net" Version="2.1.0" />
    <PackageReference Include="Microsoft.Extensions.CommandLineUtils" Version="1.1.0" />
    <PackageReference Include="System.ValueTuple" Version="4.3.0" />
  </ItemGroup>
</Project>

I think we should all take a step back and look at the current progress of the simplification effort and decide if it is good enough now, because I think that it is.
It's working people.

@AlgorithmsAreCool Thanks a lot for the feedback, I'm glad you are happy with the progress we've made. If I look back from when we announced that we were moving from project.json -> csproj to now, we've added a lot over the old csproj:
Project:

Smart defaults. AssemblyName, Default Namespace, etc now have sensible defaults and don't need to be specified by default.
No more GUIDs. :)
Implicit language-specific/target-specific props/targets via the Sdk attribute
Metadata as attributes, so you can say <PackageReference Include="Newtonsoft.Json" Version="9.0.1"/> instead of <PackageReference Include="Newtonsoft.Json"><Version>9.0.1</Version></PackageReference. This works with all items not just package references.
Implicit configurations - by default all projects have two configurations; Debug|AnyCPU and Release|AnyCPU with sensible defaults. (Note: We currently have 6 configs in the RC, but 2 by time we ship).
Implicit globbing support, with a default set of common globs so you don't need to specify them, which projects can override if they'd like
Simplified project references, no need to specify the Name or GUID metadata

Targeting:

Friendly TFM names in <TargetFramework>, so you don't need to specify 'or`.
Multi-targeting support via the <TargetFrameworks> property, so that a single project can produce multiple outputs targeting multiple frameworks/platforms
Implicit conditional compilation symbols based on the target framework you target
Support for conditional items such as references, packages, and compile items and have VS respect them, so you can differ them based on target framework.

NuGet:

<PackageReference /> which enables you specify (just) your top-level package dependencies inside csproj along with your other dependencies
Transitive package references
NuGet Restore via msbuild
Produce a NuGet package via msbuild
Background restore, so packages are restored in the background while the project is open.

Visual Studio:

Real support for globbing ("***.cs", etc) - no longer does VS expand the glob when you delete a file, or add an include when you add a file already included in the glob. VS also automatically picks up addition of new files (or deletions of existing files) automatically.
Auto refresh. VS will automatically pick up changes from disk when you switch branches or modify it another editor and just apply the differences without reloading the project
Edit while open. You can now edit the project file while the project is open, and have VS pick up the changes on Save.
New Dependency node (replacement for references) that shows packages, references, project references, SDKs and their dependencies.

Above is just the list that I can remember off the top of my head, I'm sure I've missed a bunch. Anyway, we've been on a journey that will continue long past this release. Please keep the feedback coming!

@davkean That is indeed a very big improvement syntax wise! That said, the real problems arise when a build requires more than simply declaring dependencies and conforming to standard .NET toolset. This is where Gradle shines and I still wonder why it is not used at least as a source of inspiration/lessons learned. This project format looks like Maven pom.xml with a much better syntax, which is nice, but there is a reason why Gradle or SBT were created.

That said, the real problems arise when a build requires more than simply declaring dependencies and conforming to standard .NET toolset. This is where Gradle shines

@slorion What do you mean? The new clean csproj is built on msbuild which is a full build system. I don't know much about Gradle, but in terms of build system, you can do pretty much whatever you want with msbuild and develop complex builds. That's one of the reasons they switched back from project.json to (clean) msbuild projects.

@xoofx What I meant is that once you get past simple builds, you need to get into the innards of msbuild. For having done that in the past, I cannot say it is a pleasing experience to say the least.

@slorion I see your concern, so yes, the msbuild syntax sucks and I would not mind switching to a more simpler DSL + curly braced syntax (e.g ala Graddle)... but one step at a time... 😉

👍 to the great work of the new .csproj format.  @davkean and team have been impressively busy and productive over in the CPS repo and they have been a marvel to watch.  The new format is remarkable and nothing less than impressive. (But as @xoofx suggests, it's high-time to apply that magic to the arcane and cryptic .sln file. 😉)
Along such lines, that is not to say that we still cannot make great improvements to the IDE to further the goal here.  In my mind, the goal of the issue is to create an experience that allows:

Viewable in a desired data format (much like how .NET developers can choose to work in C#/VB/F#)
Can hand-edit like a champ (seems like this is closer to reality now ala above)
Visual/designer-tooling friendly (sort of the initial driver here)

There are two camps here: those that enjoy the CLI and ... those who don't. :)  Both of these camps should be considered going forward to create a successful development paradigm.
The purpose of using a POCO-based development scheme is that the schema is automatically generated for you from the class definitions, and designer tooling automatically "lights up" when directed towards it.  It makes it easier for both developer and tooling to use for development.
However, I am definitely open to any other innovative ideas and directions to accomplish this goal.  I really enjoy reading @gulshan's thoughts and efforts in the different threads for a different object notation.  Gradle seems to be the super hot cake right now, so maybe there might be something worth learning and integrating there.   Maybe some cross between its format and a visual tooling integration of  @ionoy's great work with AmmyUI (imagine working with a VS/MSBuild file but with monster intellisense on steroids) is the answer?  To be continued. :)

I'm new to C# and .NET in general.  Hearing about Core made me excited to learn C#.  I booted up VS2015 and created a solution.  I immediately felt at home, and things like project.json definitely contributed to that feeling.
I'm not the kind of developer who stays in their comfort zone.  You know the type: too lazy/afraid to learn something new.    Looking through the patch notes though, I must say the team has made some nice improvements.
If MSBuild support entices people to migrate legacy projects thus contributing to the future success of the platform, then I can get on board with it.  But what if the cost of that is scaring away new developers?  It's just one of those things that makes me think, "There must be a better way".  As a padawan I can't say I know the way, but even a padawan can share their perspective and insight.
Luke: Master, moving stones around is one thing.  This is totally different.
Yoda: No!  No different!  Only different in your mind.  You must unlearn what you have learned.
Luke: All right, I'll give it a try.

I think the downside, is that on the whole VS studio is too opinionated either way.  I have been a .net developer since .net 1.0 back in 2003.  I have always hated MSBuild probably mostly because in my mind it is so closely aligned with the worst of Microsoft known as TFS.  I have always preferred what was known as the ALT.net stack of the day.  That's not say that there haven't been great products in the .net stack as whole.  Probably most Devs have a Love/Hate relationship with VS Studio, just like most Java Devs have a love/hate relationship with Eclipse or IntelliJ.
Personally I think this is very clearly portrayed in the comments above, there certainly isn't the ONE right way.  Honestly whichever way the decision went, there were going to be losers.  Yet another Brexit/Trump choice!
I did really like the Project.json format.  Found it very simple to grok and was easy to hand edit.
But saying that on the whole, I do like the new csproj format,
What I don't like and specifically the issue I have now, is that I am working in VS 2017 RC, we're just a couple of days away from being released, and some basic things just aren't working.  Which are a direct result of json/csproj shift, and have had a direct impact on my productivity.
I'm used to working with OS products, and understand the risks of developing new software on release candidates stuff, but when a notifications goes out a few weeks ago, warning of the change, and steps to take to prepare for it.  But yet things just don't work

dotnet ef
System.IO.FileNotFoundException: Could not find file 'C:\Users\gary\code\portal\src\DBDummyUI\project.json'.
File name: 'C:\Users\gary\code\portal\src\DBDummyUI\project.json'
I have had to basically read the internet cover to cover to only find this post
https://github.com/aspnet/Tooling/blob/master/known-issues-vs2017.md
Which kinda informs me that EFcore tooling will not work with the new csproj format.  Yet, we're still only days away from a release.
It's not a moan, on the team or Microsoft.  I know at the end of the day, it was always going to be a hobsons choice.   However, I do think there is a lot of scope in the argument of giving the community the choice of format, instead of giving them an opinionated implementation, based on the fact that it works with MSbuild,  which is ok if you're going to use MSBUILD but what if you're not ?
Apologies for the long ramble!

@garywoodfine you might be missing a reference to the msbuld version of the ef tools in your csproj (note the version number):
<ItemGroup>
  <DotNetCliToolReference Include="Microsoft.EntityFrameworkCore.Tools.DotNet" Version="1.0.0-msbuild3-final" />
</ItemGroup>

@dasMulli  Thanks
I had
<DotNetCliToolReference Include="Microsoft.EntityFrameworkCore.Tools.DotNet" Version="1.1.0-preview4-final" />`
But now when I try
 <DotNetCliToolReference Include="Microsoft.EntityFrameworkCore.Tools.DotNet" Version="1.0.0-msbuild3-final" />
I just get "ef is not recognized as an internal or external command"

@garywoodfine, @dasMulli: Can you please move this support discussion out into a relevant issue? 😄

I'm late to the game but wanted to chime in here:
Getting rid of project.json in favor of an MSBuild based alternative will pretty much kill my present company's ambitions of supporting .NET at scale. I've recently inherited some .NET based work that needs to be brought current and was pretty excited to see what has changed in the world of .NET over the past decade (I haven't actively used .NET since 2010 and stopped using Windows altogether in 2013). With a move back to Visual Studio, even if there is support for Mac, it's looking unlikely that there will be interest in supporting Microsoft platforms moving forward.

@udev MSBuild is now cross-platform as it is built with .net core. Moving back to MSBuild doesn't mean going back Visual Studio. The command line tools and VSCode with Omnisharp can be used to develop .net everywhere.

I'm doing work on a Mac with VS Code and Visual Studio Mac, and the command line, and while I'm not a huge fan of the old MSBuild csproj, even I have to admit the new experience is kind of awesome.

I think Type Providers in C# will help a lot to fulfill the goal of this proposal.

In 20 years I have yet to work with a developer who cares one bit about proj files being in xml or some other format.
Only a handful even understand what the file actually does or how to alter it to make life easier or fix problems. This seems like work for work's sake.

We believe SDK style projects address this issue by making the project files concise. We have no plans to add new extension points to the project formats at this point.
Thanks for all the comments and discussion here.

@livarcocc - fine, like the nuget team, you aren't interested in maintaining feature compat or even parity. That seems like a move that only serves to punish the userbase thats actually interested  in things like proj formats. I really think that feedback for this feature was not segregated between "OMGPREVIEW fanboys", the project file casuals that make up most of the .net developer populace, to whom this sounds like a good idea from the surface view (simpler always sounds better, until you need a feature that got chopped), and power users for whom an implicit content and still undocumented project file is an echo of web site projects and a looming compilation and automation disaster.
Can you at least guarantee or promise we won't be forced to use these problematic and inferior SDK style project formats?

Can you at least guarantee or promise we won't be forced to use these problematic and inferior SDK style project formats?

In what way do you believe SDK-style projects are inferior?

Please point out anything non-factual. This is what it looks like from the outside.

They require package reference style nuget. This means losing useful package things like adding files to a project as part of a (private) package, or providing simple xdt config transforms or running a powershell script to cover all the other possible gaps. It also means not knowing what dependencies are actually going to be included until the project is built and the output is inspected. I can't make a private package that is as useful to my team with package ref as is possible with package config.

there isn't an explicit list of things to be included in the compilation.

Stray files were a headache with web site projects, web app projects fixed that, but SDK brings back that indeterminism for all types of projects. Tools that create extra files or folders in the project filesystem have to be cleaned up after, sloppy development/filesystem habits create more problems than before, and one of my personal favorites vssscc and vssspc vestigial visual source safe files get even more foothold in version control.

inspecting projects across codebases can't be done by looking at the proj file, now the constituent files to include (which ones?) need to be downloaded. Hopefully VCS or FS or the user doesn' have a whoops and miss a file, because the project won't know unless it compiles.

automating some changes to projects is significantly more difficult for the same reasons as inspection, but the dearth of defaults and that so few of them dare to be documented - makes reworking any existing tooling a time sink swag session.

The history of this format reads like it's the recovery from the A-ha moment when you all (mostly) realized that json is great for data exchange but horrible for configuration. Instead of taking that lesson you forged ahead when it wasn't necessary in the first place. It didn't need to be done, there are other things needing modernization (sln files, easier wcf rest support, etc.)
Hopefully the impetus was not inspired by statements like "my company will not adopt/will abandon netcore hinges on a project format" because they are empty and dumb statements.
This is what I can muster before breakfast on my phone, and may get a few typographical or formatting edits when I can see more than a paragraph at a time.

@StingyJack Parts of that don't ring true to my experience. I know of packages that add files to projects can be done using a .props file. It never seemed useful to me to keep the dependency graph in source control, but you can do that with a lock file: https://docs.microsoft.com/en-us/nuget/consume-packages/package-references-in-project-files#enabling-lock-file

there isn't an explicit list of things to be included in the compilation.

From the production or consumption side? When creating packages, it's explicit except for the single built assembly.

inspecting projects across codebases can't be done by looking at the proj file, now the constituent files to include (which ones?) need to be downloaded

This is a relief to those with frequent merge conflicts who can't wait to get the rest of their projects on the newer csproj format. Having to be explicit always felt like duplication because of how basic the includes are.

automating some changes to projects is significantly more difficult for the same reasons as inspection, but the dearth of defaults and that so few of them dare to be documented - makes reworking any existing tooling a time sink swag session.

Many things were always implicit and idiosyncratic. The cleaner SDK pushes that further along the same path. I think this is the thing https://github.com/daveaglick/Buildalyzer solves.

Just to jump in and echo some of the comments:

there isn't an explicit list of things to be included in the compilation.
From the production or consumption side? When creating packages, it's explicit except for the single built assembly.

Its been awhile since I've looked at the new SDK format but I believe its from the consumption side; consider a project Layout Similar to the following:
└───Project
       A.cs
       B.cs
       Project.csproj

Based on my recollection Project.csproj will helpfully attempt to include everything under itself as part of the project format. This is bad for the reasons that @StingyJack mentions above.
The explicit nature ensures that the build system is doing what the developer asked for, not what was "helpfully found". It is very possible that a developer has forgotten to check in a source file, and unless your are explicit, could very well result in a run time failure as opposed to a build one. Consider a class library that utilizes Dependency Injection/IoC in which the classes contained within B.cs are consumed. If a Developer forgets to commit B.cs under an implicit model this is not discovered until runtime (hopefully in Internal testing, but as per Murphy at a Customer Site for sure).
There are other reasons to have extraneous files in a sub-folder that you explicitly do not want included. I know for a fact that in our large code base there are places where this is actually by design. Consider this pattern:
└───MyClassLibrary
        A.cs
        ATests.cs
        Implementation.csproj
        UnitTests.csproj

In this case you want A.cs to be included ONLY in the Implementation.csproj, whereas you want ATests.cs to be included ONLY in UnitTests.csproj. You can argue the merits of shoving this all into a single source folder (I know I have tried) but this is the reality for a lot of large development shops. It is difficult to get buy in from stake holders to refactor projects which previously "worked".

inspecting projects across codebases can't be done by looking at the proj file, now the constituent files to include (which ones?) need to be downloaded

This is a relief to those with frequent merge conflicts who can't wait to get the rest of their projects on the newer csproj format. Having to be explicit always felt like duplication because of how basic the includes are.

I would take the opposite side of this argument. We maintain 16 Branches of our code base (yeah, 16...). While on the surface I agree with you due to the number of merge conflicts there are things that can and should be done to try and minimize this. For starters ensuring that the project format is sorted in a deterministic matter (we settled on quasi-alphabetization) is helpful. I agree that having to write tooling to support this is not fun, and you can see that my GitHub is littered with tooling to do so, but the reality for us (and other Build Masters I've talked to in similar industries) is that its just par for the course.
The ability to quickly diff project files between branches is critical in understanding what is and what is not making it into the final binaries. Anything that can mux the output (by adding "indeterminism") is considered a defect from the DevOps world.

How common is the problem of forgetting to add a source file to source control (and without failing CI)? New files show up prominently using Team Explorer (Git or TFVC) or VS Code or git from the CLI (posh-git).

At least once a week internally. We have ~70 Developers averaging 200 commits a week the average commit size is 3 CSPROJ Files +/- 20 CS Files, most are changes to existing files with a few additions sprinkled in. FWIW we're using Subversion, but I doubt changing VCS would really help (we already use Ankh which provides the overly). Even your absolute best developers (your 10x devs) will occasionally make a mistake. Its inevitable at this scale and rate of change.
YMMV; apparently it doesn't happen for you, I wish I was there (more than you can know).

The ability to quickly diff folders between branches using source control is powerful, more complete than diffing csproj files in my experience. Files are the starting point, the ultimate source of truth.

We don't disagree, however the scale at which this occurs is much larger than most diffing tools respond to reasonably quickly, our branches are ~670,000 Files 60,400 Folders

We have ~5,800 CSPROJ Files, quickly performing diffs at the CSPROJ file level is much more efficient and we have massive amounts of automated tooling (both Commit Hooks and a tool similar to SapFix (we call it Tattler)) having the structured, deterministic format of the CSPROJ files is a huge boon, such that we capture most of these failures very early in the process.
As @StingyJack mentions there are other places where the functionality would be very useful for example this hits right in the feels for me:

It didn't need to be done, there are other things needing modernization (sln files, easier wcf rest support, etc.)

And FWIW you might want to take a look at this closed idea: https://github.com/dotnet/cli/issues/12858 I am working on open sourcing our tooling that does something similar @StingyJack sounds like you would benefit from it (same boat you and I on the River Styx).

If you do like the manual maintenance of all .cs files, you can put <EnableDefaultCompileItems>false</EnableDefaultCompileItems> in Directory.Build.props or a csproj.

Thank you we will be enabling this shortly. Today we do not use the new style Project Format (mostly because we do not have much .NET Core) but if all goes as planned I am sure we will need it sooner rather than later.

@aolszowka We have ~60 devs plus a lot of consultants, and i have never  seen a case where a missing source file made it through CI (not to mention compilation). The setup you describe sounds absolutely horrifying :) How in the world can a missing source file pass CI? I understand that theoretically in some cases reflection over types in an assembly could compile without error (though even that should be extremely rare), but what does it say about the CI setup if it cannot catch basic things like missing source code?
For us ( having almost 200 repos in our main github org), the new project format, and especially the implicit includes and package references (death to packages.config! :) has been a huge advantage. Previously we actually developed our own hacky little tool to deal with merge conflicts because we wasted so much time on doing it manually, but since we started using the new project format we almost never need it.

How in the world can a missing source file pass CI?
It doesn't today; because you have to explicitly include the file (that is the point of the entire conversation and example above). Therefore it kicks out in CI.

The proposal is to remove this functionality.

CI setup if it cannot catch basic things like missing source code

We completely agree, which is why we will utilize the explicit <EnableDefaultCompileItems>false</EnableDefaultCompileItems> mentioned above. 👍
It was probably added to support a similar scenario.

Previously we actually developed our own hacky little tool to deal with merge conflicts because we wasted so much time on doing it manually, but since we started using the new project format we almost never need it.

This looks like it was deprecated by the use of PackageReference; we previously had a similar tool to yours to sort package.config in a deterministic manner as you did. That being said you still encounter the same issue today though, which is why our new tooling simply enforces that PackageReference are sorted in a deterministic manner (alphabetized by the Include attribute).
The same issue exists today for just about any attribute. For our devs its most painful when dealing with <Compile>, <ProjectReference>, <PackageReference> tags as these have high rates of change for us, hence we enforce deterministic ordering to give the merging tools a fighting chance at the correct solution.
I assume this is what you mean when you say:

we almost never need it.

I would be interested to hear what other corner cases you encounter; it seems like we're not alone.

@petertiedemann  - keep in mind it not just missing files, it's extra files.

This is a relief to those with frequent merge conflicts who can't wait to get the rest of their projects on the newer csproj format. Having to be explicit always felt like duplication because of how basic the includes are.

@jnm2 - Perhaps the solution to this would have been to reliably order most of the contents of the project file, as should be done with every other computer generated non-data file, so changes were not appearing haphazardly in the file. That would probably eliminate much of the angst by allowing most merge tools to handle it automatically and it would have been a simpler fix. However it alone would not have helped the merge and compare tools built into the world's premiere IDE that have reached a new all time low in quality.
Every day, I need to be able to do more with less. Finding and fixing  a bad pattern that's been repeated in hundreds of projects is harder without the file manifest and with so many still undocumented defaults.
Re: packages, I mean that now I can make a dll only package, but I can no longer make a package that co-workers can add that will also take care of configuration of the consuming project, or add CS or TT files to the project.  Those all now have to be done manually.

How in the world can a missing source file pass CI?

It doesn't today; because you have to explicitly include the file (that is the point of the entire conversation and example above). Therefore it kicks out in CI.
The proposal is to remove this functionality.

CI setup if it cannot catch basic things like missing source code

We completely agree, which is why we will utilize the explicit <EnableDefaultCompileItems>false</EnableDefaultCompileItems> mentioned above. 👍

@aolszowka Sorry if i wasn't clear. We are already using the implicit includes, and have never encountered similar problems (as i mentioned we see the implicit. includes as a huge productivity improvement over explicit ones).  My point was that, given implicit includes, how can you have your CI miss something like this except in some very exotic scenarios? It would seem that in the 90+% case you will simply have a missing type error somewhere and fail to compile. If you are using reflection / automated DI then i guess it could compile, but then i would be very worried if a test did not catch the problem.

This looks like it was deprecated by the use of PackageReference; we previously had a similar tool to yours to sort package.config in a deterministic manner as you did. That being said you still encounter the same issue today though, which is why our new tooling simply enforces that PackageReference are sorted in a deterministic manner (alphabetized by the Include attribute).

Actually, we rarely have the issue today, because you now only have to deal with the package reference, and not the duplicated entries in the csproj file. I do agree on maintaining it sorted though.
Our project files are almost empty actually. We have a shared project file that we import that have things like copyrights and namespace setup, and the rest we just leave to the implicit includes / default behavior. A typical project file is ~20-30 lines.

Perhaps the solution to this would have been to reliably order most of the contents of the project file, as should be done with every other computer generated non-data file

For most projects, folks want to leave behind the idea that a csproj is a computer-generated file.

Perhaps the solution to this would have been to reliably order most of the contents of the project file, as should be done with every other computer generated non-data file

For most projects, folks want to leave behind the idea that a csproj is a computer-generated file.

and with so many still undocumented defaults.

Are there any undocumented defaults? The link I gave earlier seemed pretty thorough in the area I read.

Doesn't have explicit includes just move the problem? Back before SDK projects, I often saw commits that included a new source file but forgot to add the project file change. Either way these were usually caught by CI due to being referenced by other files, but it was pretty easy to make this mistake.

how can you have your CI miss something like this except in some very exotic scenarios? It would seem that in the 90+% case you will simply have a missing type error somewhere and fail to compile.

If you are using reflection / automated DI then i guess it could compile

It seems like you answered your own question? I am not sure why you feel the need to debate this point when you know the answer?
As @StingyJack mentions you don't account for the extra files (the Unit Test Scenario I listed above for you).
Regardless we have a documented work around; I am not sure why there is need to continue any discussion on it?

because you now only have to deal with the package reference, and not the duplicated entries in the csproj file. I do agree on maintaining it sorted though.

And this new package format does nothing to solve these problems (again what @StingyJack is pointing out here). For a trivial number of PackageReferences/ProjectReferences this is managable, but when you get upwards of 50 of them it gets out of hand without any type of sorting enforced.
@owenneil

Doesn't have explicit includes just move the problem?

Yes; but it moves it back to the Developer (earliest in the process), and even better it gives your gated check-in a fighting chance to interrogate the CSPROJ Files on add; we have a commit hook that does exactly this (If CS File is added or removed ensure that the appropriate changes were made to the CSPROJ file).

@petertiedemann - keep in mind it not just missing files, it's extra files.

But in a "normal" setup this really wouldn't be a problem, would it? In all of our ~200 repos (everything from web services, constraint engines to domain specific language parsens and compilers) we do not have source files in the project folder that we do not want to include (in either the ones using the new and the old project format). And even if you do have some exotic projects with this problem, you simply disable the implicit includes or explicitly exclude them.

It seems like you answered your own question? I am not sure why you feel the need to debate this point when you know the answer?
...
Regardless we have a documented work around; I am not sure why there is need to continue any discussion on it?

I guess because the opinion voiced by you and @StingyJack seemed to be that implicit includes as default was poor design, but the cases brought up were pretty exotic, meaning that implicit includes indeed does seem to be an excellent design choice. The unit test scenario that was described basically goes against common practice for how to structure projects, and it is not one i have ever seen before. The runtime reflection CI/CD scenario is just scary design by itself, and it seems almost unthinkable that no tests would exist to fail in that case ( you have defined a type that is never used in any test or other project?).

And this new package format does nothing to solve these problems (again what @StingyJack is pointing out here). For a trivial number of PackageReferences/ProjectReferences this is managable, but when you get upwards of 50 of them it gets out of hand without any type of sorting enforced.

Well the PackageReference certainly helps a lot. Before we had people giving up on rebasing branches because of conflicts in dll references, now we rarely need to spend time on it.
But you projects have ~50 references? Thats quite a bit i must say, but i am still surprised that they would change often enough to cause signifcant problems. We have considered expanding our tool to deal with PackageReferences as well, but it would take far more time to implement it that than we spent on manually dealing with it.

Are there any undocumented defaults? The link I gave earlier seemed pretty thorough in the area I read.

Depends on the context; I read that to indicate that the project file is still a black box in some respects. While Microsoft has made HUGE Strides in documenting the behavior and intent of the Project Format in the last few years with Microsoft Docs (and we thank them for this!).
The first one that comes to my mind is the behavior of References in the newish system; there are some very subtle bugs around the restore logic. See this NuGet Issue https://github.com/NuGet/Home/issues/8272 many of these are not noticed until they are attempted at scale and only after careful evaluation.
I am sure we could continue to cherry pick behaviors; but its most likely irrelevant to the discussion at hand.
@petertiedemann

I guess because the opinion voiced by you and @StingyJack seemed to be that implicit includes as default was poor design,

I don't believe I ever used the words "poor design". I noted that:

Anything that can mux the output (by adding "indeterminism") is considered a defect from the DevOps world.

Which again, can be worked around simply by using the posted work around: <EnableDefaultCompileItems>false</EnableDefaultCompileItems>

but the cases brought up were pretty exotic, meaning that implicit includes indeed does seem to be an excellent design choice.

As to your point of exotic or not: One man's exotic is another mans common. Its the world we live in, and the tools were/are written such that you are free to suit them to your needs. I think StingyJack's frustration (along with mine) is that these scenarios are written off as corner cases (as you do below).

The unit test scenario that was described basically goes against common practice for how to structure projects, and it is not one i have ever seen before.

The runtime reflection CI/CD scenario is just scary design by itself, and it seems almost unthinkable that no tests would exist to fail in that case ( you have defined a type that is never used in any test or other project?).

Hey neither had I; but we're here today aren't we? (See the above) I think your inability to accept that the system is being used in perverse ways is causing you a lot of frustration and I apologize. I am not here to advocate that this is by any means good or acceptable nor to question the design persay. I am simply trying to be inclusive to current use cases that are affecting consumers of the product.

But you projects have ~50 references? Thats quite a bit i must say, but i am still surprised that they would change often enough to cause signifcant problems.

Oh yes! Easily. The problem is so bad I wrote a tool to help visualize it! (Shameless Plug: https://github.com/aolszowka/MsBuildProjectReferenceDependencyGraph) in fact there is a CI Process around automatically generating these graphs over every commit just so we can keep developers apprised of the next low level change that is bound to burn you on your next svn update! Those graphs are committed in their own repository so people can keep updating to get the latest.
Here's an anonymized version of a very commonly used Solution File by most Developers. Throw it in your favorite program that supports rendering dotGraphs (GraphViz for example, and its so complex WebGraphViz will not work) https://gist.github.com/aolszowka/a93ea5545d54344c61f66830fae90c4e it takes about 15-20 minutes to render on my personal work station. Oh by the way that is just ProjectReferences the tool makes no attempt to graph PackageReferences (yet, I accept pull requests!).
Its been a real joy to watch the Roslyn team experience large solutions in Visual Studio (Roslyn.sln would be considered on the small side internally). On the plus side they have made HUGE strides towards fixing it (because it burns them day to day), so at least its now possible to load these in VS 2017+ I am still hopeful they reach the end of the road soon and realize they need to make Visual Studio 64bit so then we aren't crashing 3-5 times a day due to OOM errors.

but it would take far more time to implement it that than we spent on manually dealing with it.
Oh how I envy you, but remember much like puppies and kittens: They start out small, but the grow up! At one time these  branches were maintainable (probably why the attitude was "well what's one more?").

At least once a week internally. We have ~70 Developers averaging 200 commits a week the average commit size is 3 CSPROJ Files +/- 20 CS Files, most are changes to existing files with a few additions sprinkled in. FWIW we're using Subversion, but I doubt changing VCS would really help (we already use Ankh which provides the overly). Even your absolute best developers (your 10x devs) will occasionally make a mistake. Its inevitable at this scale and rate of change.

@aolszowka
FWIW, my team had this problem all the time years ago when we were on SVN. After the migration to Git it never happened anymore. Especially since we started gating checkins on CI Passing.

@AlgorithmsAreCool

Especially since we started gating checkins on CI Passing.

For sure; I think there is some confusion here; we gate these check-ins today via a Subversion Commit Hook (which we keep metrics on which is why I can tell you how often it happens), however the Subversion commit hook needs to utilize the CSPROJ to determine what is "correct" see this comment:

Yes; but it moves it back to the Developer (earliest in the process), and even better it gives your gated check-in a fighting chance to interrogate the CSPROJ Files on add; we have a commit hook that does exactly this (If CS File is added or removed ensure that the appropriate changes were made to the CSPROJ file).

I guess because the opinion voiced by you and @StingyJack seemed to be that implicit includes as default was poor design, but the cases brought up were pretty exotic, meaning that implicit includes indeed does seem to be an excellent design choice

If I didn't say that, I mean it, and I dont say that just to be combative or flippant. There is nothing exotic about having a manifest of what is expected to be included into the final result.  Lack of that manifest opens the door for unexpected ("exotic?") things to be included into the final result.  Every other profession that creates something has an explicit list like this. To put it differently...
Would you eat a meal when you knew the chef was not in control of the ingredients and preparation of that meal?
Would you permit a renovation of your home when you knew the general contractor was not checking the gauge of electrical wiring used or if it was copper or aluminum before installing it?
Would you take a medication if you knew the producer was not in total control of the manufacturing and packaging of that medicine?
These other "creation" industries may be regulated and thus required to use an explicit list, but the ones that aren't will use one because its necessary for planning and because it is an easy way to have a reasonable expectation of similar quality of output between different efforts. The second part is the key for us; we cant incrementally improve upon something if that something can change in quality without us even knowing it. I recently discovered something like this had been happening in a python project I work on. Some builds would just be weird, some unusable. I found that early on, someone had added a bunch of packages into the setup.py file and missed the comma between an upper and lower version range. It was an easy thing for at least 5 skilled developers to miss for almost a year. Pip (python's nuget.exe) read the whole thing as the lower version with some prerelease tag and started always including the latest version even if it was an alpha package.
Implicit code inclusions, wildcard/floating version dependencies and automatically included transitive references are a convenience, but this convenience comes with risks to your projects success that are very real. With the latter putting the project at the mercy of any package author in the dependency chain's release schedule and release quality (or un-release schedule - see "left-pad"). Assuming this risk should be an opt-in and not be the default. Its not setting programmers up for the "pit of success" by any stretch.
Also, we aren't usually involved in making software that has immediate Life or Death consequences, but we are all involved in making software that has Quality of Life consequences for users, ourselves, and our fellow programmers. The .net community tried this implicit file experiment in the .net v1 -2 era with Web Site Projects, and while it was great when you had the one exotic use case where you needed to update compileable files on the fly, it sucked to have to manage everything in the project based on the presence or absence of files (or phantom files - .dll.refresh) or specific file extensions (.excluded). But what really sucked was when some kind of pollution (like an unintended file, or the wrong version of a file) crept in and you had to troubleshoot the result. Anyone wanting to try that out is still able to do so, but most of us use Web Application Projects - where we can control the inputs and outputs to achieve a predictable result - instead.

@StingyJack:

There is nothing exotic about having a manifest of what is expected to be included into the final result. Lack of that manifest opens the door for unexpected ("exotic?") things to be included into the final result. Every other profession that creates something has an explicit list like this.

Why isn't Git enough of a "manifest" to you? If you are including heaploads of files in Git that aren't supposed to be there or as a part of the final product, perhaps you should revise your development process?

@asbjornu - I think you mean "version control system" and not specifically git, correct? This isnt about version control in the first place, and AFAIK msbuild still requires the files to be present on a filesystem, and not in the VCS of our choosing. The abridged comment I made above regarding project files with all these implicit inclusions and defaults is about the project file. It was never a heap of files that caused problems with web site projects, it was always that one file that resulted several hours of troubleshooting.
I'm curious to know how you would entertain those three questions I posed about other professions, because the answer from me is going to be No, No, and No.  If you also would answer "No" to those three, then consider the point of view of a business of our profession. Would they trust a programmer to make something important for their business who does not control what goes into the program?
If you want to take a shortcut with implicit includes, and you can manage the associated risk, I've got no complaints. But making all of these implicit includes the default behavior so that I have to do work now to mitigate a risk that I did not have to do with the prior format is something I am going to complain about.

@StingyJack:

I think you mean "version control system" and not specifically git, correct?

Nope, I mean Git, since most other version control systems don't have a cryptographically verifiable history, signed commits and signed tags. With these in place, you have a pretty strong source of truth for what should and should not be considered a part of the resulting application.
If you currently allow developers to add any strange file to your VCS without any code review, no verification, no sign-off or any other editorial process in place, I say your development process is at blame here, not the project system. Most development platforms take the same route here of implicit inclusion; Node.js, Ruby, Python, PHP, Go, Rust, Docker, etc.

Would they trust a programmer to make something important for their business who does not control what goes into the program?

Why do you claim the programmer doesn't have control over their VCS (preferably Git)?

Nope, I mean Git, since most other version control systems don't have a cryptographically verifiable history, signed commits and signed tags. With these in place, you have a pretty strong source of truth for what should and should not be considered a part of the resulting application.

A "cryptographically verifiable history, signed commits and signed tags" does not describe intent of the developer. You can cryptographically sign anything you want; that property does not mean that its contents should be trusted (and is the jist of @StingyJack 's argument).

Why do you claim the programmer doesn't have control over their VCS (preferably Git)?

This assumes that the developers in the system are competent or at least not malicious. Ask event-stream how that worked out for them (and everyone upstream that got burned "I don't know what to say" for me was the quote of 2018).

Hi folks,
We think for most people, automatically including all files with the right extension makes sense.  For those who don't want that behavior, you can turn it off by setting the EnableDefaultItems property to false.
This is in line with the philosophy we had when designing the updated project files, which was to have sensible defaults that could be overridden when necessary.
There's been a ton of discussion on this issue and it seems like it's been a catch-all for any comments about the project file format.  That makes it less likely that we will pick up on and address feedback.  If you have concrete things causing you trouble, I recommend creating new issues for those.
Thanks!
Daniel

@aolszowka:

A "cryptographically verifiable history, signed commits and signed tags" does not describe intent of the developer.

The commit log should reflect the developer's intent. Every single commit can be signed to identify the developer of said code. A code review signed off by someone else can double-verify the intent. A signed and tagged merge-commit of the reviewed commits can triple-verify the intent. How many verifications do you need?

You can cryptographically sign anything you want; that property does not mean that its contents should be trusted (and is the jist of @StingyJack 's argument).

Can no one in your team be trusted, not even a chain of command that are able to sign off on code reviews or tagged merge-commits?

Why do you claim the programmer doesn't have control over their VCS (preferably Git)?

This assumes that the developers in the system are competent or at least not malicious.

If all your developers incompetent and/or malicious, having explicit includes in projects files won't make a difference. If having three different people at different levels in the chain of command cryptographically sign and thumbs up a range of commits isn't sufficient to you (it is to code under the submission of a PCI-DSS review process) then nothing will ever be.

Ask event-stream how that worked out for them (and everyone upstream that got burned "I don't know what to say" for me was the quote of 2018).

Irrelevant and incomparable to the process I'm describing. If a hostile take-over of a Git repository is possible in your process and VCS, your process and VCS is broken, not your project system.


ssl

im getting ERR_SSL_PROTOCOL_ERROR
is there a way to server files with working ssl?
i want to use public ip or able to link it behind cloudflare with domain
is there env for custom crt?

Could you tell us a bit more about your config (domain name or IP you use, real or self-signed cert...)?
FrankenPHP uses Caddy under the hood, refer to its documentation regarding TLS: https://caddyserver.com/docs/automatic-https

I used default command docker run -v $PWD:/app/public \     -p 80:80 -p 443:443 \     dunglas/frankenphp
and tried to access with public ip and domain name behind cloudflare. both with ssl error

As stated in the readme, using IPs requires additional configuration: https://caddyserver.com/docs/automatic-https#hostname-requirements

ok, i edited and binded new config. seems Automatic HTTPS is working and website working too. great project

btw there is no php.ini in /usr/local/lib/php.ini in docker
root@b44674c5bdca:/app# cat /usr/local/lib/php.ini
cat: /usr/local/lib/php.ini: No such file or directory

You need to copy one (from https://hub.docker.com/_/php):
mv $PHP_INI_DIR/php.ini-development $PHP_INI_DIR/php.ini
# or
mv $PHP_INI_DIR/php.ini-production $PHP_INI_DIR/php.ini

I solve similar problem with these configurations:

Enable Cloudflare DNS proxy for SSL

Leave your server name as a domain name (example.com) without adding http:// or :80

Inject global configuration for Frank / Caddy
CADDY_GLOBAL_OPTIONS="local_certs"

Restart your server

Enjoy your SSL managed by Cloudflare


Log Analytics query are using old query language

The Log Analytics query shown are using the old query language, should be updated to KQL

Document Details
⚠ Do not edit this section. It is required for docs.microsoft.com ➟ GitHub issue linking.

ID: 3aa2f48e-a8f8-fb03-753b-9e3b76075b96
Version Independent ID: 2554dcd1-27a2-3a32-4097-b17dd261a1ad
Content: Integrate security solutions in Azure Security Center
Content Source: articles/security-center/security-center-partner-integration.md
Service: security-center
GitHub Login: @rkarlin
Microsoft Alias: rkarlin

#please-close


add migrate_keys command

Add shortcut command migrate_keys for MIGRATE…KEYS key1 [key2 ...] command.
Also fixed debug_sleep.

Current coverage is 95.52% (diff: 100%)

Merging #187 into master will increase coverage by 0.21%

@@             master       #187   diff @@
==========================================
  Files            55         55
  Lines          7073       7166    +93
  Methods           0          0
  Messages          0          0
  Branches        573        583    +10
==========================================
+ Hits           6741       6845   +104
+ Misses          243        236     -7
+ Partials         89         85     -4

Powered by Codecov. Last update f504886...8cdcaf0


Foundry Fork Testing Error: Unable to Test Historical Blocks with Specified Block Number

Description
Foundry supports testing in a forked environment using what they call Forking Mode with the following terminal command:
forge test --fork-url <your_rpc_url>
I can successfully run my foundry tests in a forked Hedera testnet using Hashio.
> forge test --fork-url https://testnet.hashio.io/api -vvvv
[⠢] Compiling...
[⠰] Compiling 1 files with 0.8.23
[⠔] Solc 0.8.23 finished in 1.13s
Compiler run successful!

Running 2 tests for test/foundry/TodoList.t.sol:TodoListTest
[PASS] testNumberOfTodos() (gas: 9394)
Logs:
  Current number of Todos: 9

Traces:
  [9394] TodoListTest::testNumberOfTodos()
    ├─ [2325] 0x124e4d4a40bdC6FFfda736078896eD16ECf1cA32::getNumberOfTodos() [staticcall]
    │   └─ ← 9
    ├─ emit log_named_uint(key: "Current number of Todos", val: 9)
    └─ ← ()

[PASS] test_createTodo_returnsNumberOfTodosIncrementedByOne() (gas: 59166)
Traces:
  [59166] TodoListTest::test_createTodo_returnsNumberOfTodosIncrementedByOne()
    ├─ [2325] 0x124e4d4a40bdC6FFfda736078896eD16ECf1cA32::getNumberOfTodos() [staticcall]
    │   └─ ← 9
    ├─ [51026] 0x124e4d4a40bdC6FFfda736078896eD16ECf1cA32::createTodo("A new todo for you!")
    │   └─ ← 10
    └─ ← ()

Test result: ok. 2 passed; 0 failed; 0 skipped; finished in 2.89s

Ran 1 test suites: 2 tests passed, 0 failed, 0 skipped (2 total tests)

The issue is when I try to specify a block from which to fork with --fork-block-number
See the error below:
> forge test --fork-url https://testnet.hashio.io/api --fork-block-number 6386005
[⠢] Compiling...
No files changed, compilation skipped
2023-12-27T01:07:00.475866Z ERROR sharedbackend: Failed to send/recv `basic` err=failed to get account for 0x0000000000000000000000000000000000000000: (code: -32603, message: [Request ID: 4cf11fed-be6f-492f-b0c1-17c1490ac888] Unknown error invoking RPC, data: None) address=0x0000000000000000000000000000000000000000

Running 1 test for test/foundry/TodoList.t.sol:TodoListTest
[FAIL. Reason: failed to deploy contract: backend: failed while inspecting: Database error: failed to get account for 0x0000000000000000000000000000000000000000: (code: -32603, message: [Request ID: 4cf11fed-be6f-492f-b0c1-17c1490ac888] Unknown error invoking RPC, data: None)] setUp() (gas: 0)
Test result: FAILED. 0 passed; 1 failed; 0 skipped; finished in 20.49s

Ran 1 test suites: 0 tests passed, 1 failed, 0 skipped (1 total tests)

Failing tests:
Encountered 1 failing test in test/foundry/TodoList.t.sol:TodoListTest
[FAIL. Reason: failed to deploy contract: backend: failed while inspecting: Database error: failed to get account for 0x0000000000000000000000000000000000000000: (code: -32603, message: [Request ID: 4cf11fed-be6f-492f-b0c1-17c1490ac888] Unknown error invoking RPC, data: None)] setUp() (gas: 0)

Encountered a total of 1 failing tests, 0 tests succeeded

Steps to reproduce

Unzip the project below and open it in vscode
foundry-hedera-fork-testing.zip
edit the .env and add in your account id and private key
Deploy the TodoList.sol contract using the following command:
forge create --rpc-url https://testnet.hashio.io/api --private-key <HEX_Encoded_Private_Key> contracts/TodoList.sol:TodoList
Once forge is done deploying the smart contract, in the terminal copy the Deployed To evm address and replace the EVM address on line 10 in the file /test/foundry/TodoList.t.sol
I usually wait ~15 minutes after deploying to grab the contract's create transaction block number from hashscan

and then run the forge command to fork test at that specific block number
forge test --fork-url https://testnet.hashio.io/api --fork-block-number 6386004

Notice the error:
[⠢] Compiling...
No files changed, compilation skipped
2023-12-27T01:07:00.475866Z ERROR sharedbackend: Failed to send/recv `basic` err=failed to get account for 0x0000000000000000000000000000000000000000: (code: -32603, message: [Request ID: 4cf11fed-be6f-492f-b0c1-17c1490ac888] Unknown error invoking RPC, data: None) address=0x0000000000000000000000000000000000000000

Running 1 test for test/foundry/TodoList.t.sol:TodoListTest
[FAIL. Reason: failed to deploy contract: backend: failed while inspecting: Database error: failed to get account for 0x0000000000000000000000000000000000000000: (code: -32603, message: [Request ID: 4cf11fed-be6f-492f-b0c1-17c1490ac888] Unknown error invoking RPC, data: None)] setUp() (gas: 0)
Test result: FAILED. 0 passed; 1 failed; 0 skipped; finished in 20.49s

Ran 1 test suites: 0 tests passed, 1 failed, 0 skipped (1 total tests)

Failing tests:
Encountered 1 failing test in test/foundry/TodoList.t.sol:TodoListTest
[FAIL. Reason: failed to deploy contract: backend: failed while inspecting: Database error: failed to get account for 0x0000000000000000000000000000000000000000: (code: -32603, message: [Request ID: 4cf11fed-be6f-492f-b0c1-17c1490ac888] Unknown error invoking RPC, data: None)] setUp() (gas: 0)

Encountered a total of 1 failing tests, 0 tests succeeded

Additional context
No response
Hedera network
testnet
Version
"relay/0.38.0","jsonrpc":"2.0","id":"2
Operating system
macOS

@ebadiere please take a look

This is an intermittent problem.  The first time I compiled, deployed and ran the test on testnet, it passed.  I tried running it the next day and it failed.  I tried it later in the day and it passed.

The issue seems to be with eth_getTransactionCount.   It runs successfully when I point my relay running locally to testnet, but I get the following 400 in the console:
[2024-01-14 21:09:16.678 +0000] ERROR (mirror-node/64519 on Admins-Laptop.local): [Request ID: 37292566-85f8-493a-99bc-2598414bc91d] [GET] accounts/0x0000000000000000000000000000000000000000?transactiontype=ETHEREUMTRANSACTION&timestamp=lte:1705097782.716990097&limit=2&order=desc 504 status
    err: {
      "type": "Error",
      "message": "timeout of 10000ms exceeded",
      "stack":
          Error: timeout of 10000ms exceeded
              at MirrorNodeClient.handleError (/Users/user/projects/hedera-json-rpc-relay/packages/relay/dist/lib/clients/mirrorNodeClient.js:235:31)
              at MirrorNodeClient.<anonymous> (/Users/user/projects/hedera-json-rpc-relay/packages/relay/dist/lib/clients/mirrorNodeClient.js:206:22)
              at Generator.throw (<anonymous>)
              at rejected (/Users/user/projects/hedera-json-rpc-relay/packages/relay/dist/lib/clients/mirrorNodeClient.js:25:65)
    }
[2024-01-14 21:09:16.680 +0000] ERROR (rpc-server/64519 on Admins-Laptop.local): [Request ID: 37292566-85f8-493a-99bc-2598414bc91d] Request timeout. Please try again.
[2024-01-14 21:09:16.681 +0000] INFO (rpc-server/64519 on Admins-Laptop.local): [Request ID: 37292566-85f8-493a-99bc-2598414bc91d] [POST]: eth_getTransactionCount 400 (JSON RPC ERROR) 61112 ms
[2024-01-14 21:09:20.913 +0000] TRACE (mirror-node/64519 on Admins-Laptop.local):  Retry delay 200 ms on 'undefined'
[2024-01-14 21:09:31.139 +0000] TRACE (mirror-node/64519 on Admins-Laptop.local):  Retry delay 200 ms on 'undefined'

When running against the relay on testnet the following eth_getTransactionCount error is listed in the logs explorer:
{
  "textPayload": "[2024-01-14 21:05:07.331 +0000] \u001b[32mINFO\u001b[39m (rpc-server/62 on testnet-hashio-7db99f7789-fcrqt): \u001b[36m[Request ID: 2baf9d38-01d5-4cf4-bef1-e8da0550953c] [POST]: eth_getTransactionCount 500 (INTERNAL ERROR) 20026 ms\u001b[39m",
  "insertId": "fye1ygtp44x2utss",
  "resource": {
    "type": "k8s_container",
    "labels": {
      "container_name": "hedera-json-rpc-relay",
      "namespace_name": "testnet",
      "cluster_name": "hashio-external",
      "project_id": "hash-io",
      "pod_name": "testnet-hashio-7db99f7789-fcrqt",
      "location": "us-central1"
    }
  },
  "timestamp": "2024-01-14T21:05:07.341318767Z",
  "severity": "INFO",
  "labels": {
    "compute.googleapis.com/resource_name": "gke-hashio-external-default-pool-a0930315-szec",
    "k8s-pod/app_kubernetes_io/instance": "testnet-hashio",
    "k8s-pod/app": "testnet-hashio",
    "k8s-pod/app_kubernetes_io/name": "testnet-hashio",
    "k8s-pod/pod-template-hash": "7db99f7789"
  },
  "logName": "projects/hash-io/logs/stdout",
  "receiveTimestamp": "2024-01-14T21:05:10.600057476Z"
}

No matter what block number I provide, it looks like it always gives back the contract state from the latest block rather than from the specified historical block.

I believe the issue we're running into here is that the relay is returning stateRoot value of "stateRoot": "0x0000000000000000000000000000000000000000000000000000000000000000" in a JSON RPC block request, (eth_getBlockByNumber, or eth_getBlockByHash).  Without the stateRoot the state tree from that block cannot be rebuilt:
https://ethereum.stackexchange.com/questions/15317/how-ethereum-transaction-tree-is-formed.
The zero 32bytes hex value returned in the relay is by design.  We need to document that we do not support the forking at a given block.


[CDN] Fixes #12152: Add custom domain BYOC support.

Adds CDN custom domain BYOC support and fixes CDN-managed certs for Verizon and Microsoft SKUs. Fixes #12152 and #9894.
History Notes:
[CDN] (az cdn custom-domain enable-https:) Add BYOC support.
[CDN] (az cdn custom-domain enable-https:) Fix enabling custom HTTPS with CDN managed certificates for Standard_Verizon and Standard_Microsoft SKUs.

This checklist is used to make sure that common guidelines for a pull request are followed.

[x] The PR title and description has followed the guideline in Submitting Pull Requests.

[x] I adhere to the Command Guidelines.

add to S167

Hi again @Juliehzl, what's the timeframe for when I can get a review for this?

add to S169

@lsmith130 Could you address the comments so that we can merge this PR to fix issues

/azp run Azure.azure-cli

@MyronFanQiu, I've addressed the comments and CI failures.

add to S170

@Juliehzl is it possible to approve this PR? I've addressed all questions and requested changes.

add to S171

@haroldrandom could you take another look at this PR? I've addressed all comments and I believe it just needs code-owner approval before it can be merged.


Function with declared return type but no return

This is probably related to #811 .
Given this example:
<?php

function Example( int $i ) : int {
        if ( $i > 0 ) return $i;
}

Phan will not detect that this function can reach its end without returning a value:
$ phan noreturn4.php
$

Thanks!

It's not really related to #811
Phan is currently only checking for the presence of a return type, to minimize false positives.
BlockExitStatusChecker.php was already implemented, and will be useful to check if the method/function body will unconditionally return or throw. There's plans to use it, but it isn't used yet.
The most common type of false positive:
function Example( int $i ) : int {
   while(true) {...; return $i; }
}


The text above the button component is automatically capitalized and cannot be modified.

Description
Expect: button can be set to display raw character case.
Version
0.68.5
Output of npx react-native info
System:
OS: macOS 12.6
CPU: (8) arm64 Apple M1
Memory: 90.73 MB / 16.00 GB
Shell: 5.8.1 - /bin/zsh
Binaries:
Node: 16.18.1 -<EMAIL_ADDRESS>Yarn: 1.22.19 -<EMAIL_ADDRESS>npm: 8.19.2 -<EMAIL_ADDRESS>Watchman: 2<IP_ADDRESS> - /opt/homebrew/bin/watchman
Managers:
CocoaPods: 1.11.3 - /opt/homebrew/opt/cocoapods/bin/pod
SDKs:
iOS SDK:
Platforms: DriverKit 21.4, iOS 15.5, macOS 12.3, tvOS 15.4, watchOS 8.5
Android SDK:
API Levels: 23, 28, 29, 30, 31, 32
Build Tools: 28.0.3, 29.0.2, 29.0.3, 30.0.1, 30.0.2, 30.0.3, 31.0.0, 32.0.0, 32.1.0
System Images: android-28 | Google ARM64-V8a Play ARM 64 v8a, android-32 | Google APIs ARM 64 v8a
Android NDK: 22.1.7171670
IDEs:
Android Studio: 2021.3 AI-213.7172.25.2113.9123335
Xcode: 13.4.1/13F100 - /usr/bin/xcodebuild
Languages:
Java: 11.0.13 - /Applications/Android Studio.app/Contents/jre/Contents/Home/bin/javac
npmPackages:
@react-native-community/cli: Not Found
react: 17.0.2 => 17.0.2
react-native: 0.68.5 => 0.68.5
react-native-macos: Not Found
npmGlobalPackages:
react-native: Not Found
Steps to reproduce
It's obvious.
Snack, code example, screenshot, or link to a repository
none

Can someone answer me??

The Button.js component will automatically capitalize titles on Android. This and its styles kinda emulated a precious version of Material design, and I agree the capitalization may not make sense (along with its theming in general).
Informally we don’t recommend using Button outside the barest cases, compared to using a higher level component library which would build something custom on Pressable. It’s a pain point in the RN API.


"In-built User model" is unclear

I was initially put off by socketstream because I didn't want to hack together some prewritten authentication with my own. I thought socket stream cam prebundled with full authentication because of the line here:
"In-built User model - with modular internal authentication (authentication with external services e.g. Facebook Connect coming soon)"
This is misleading, because from what I have found in my few hours of research, socket stream does not have a user model. It has authentication and sessions which are obviously for users, but it doesn't include a "user model" (properties and methods for a user).
The above makes me believe that socketstream has already defined a user model for me (say, username, email address, etc) and has already worked it into authentication and sessions. All we have really is a user_id which is really a session_id, right?
It should probably read something like "easy sessions and authentication for users, with support for facebook connect and more coming soon."

Thanks Ian, you're quite correct.
I'm working full time on SocketStream 0.3 at the moment which is essentially a brand new piece of software. I will need to re-write the feature list entirely as so much has changed, so I'll bear this in mind.
Still on track to release the first 0.3 alpha by the end of December, so please look out for it and feel free to share your thoughts.

Great to hear from you. I'm going to use socket stream on a project over winter break, and started infrastructure research this week. Really looking forward to the release.

Hi Ian.
Closing this now as I'm about to release 0.3 (tomorrow hopefully). So far very little has been done around authentication but it provides a much better framework to build solutions on in the future.


Provide an option to output large regions as tiled tiffs

This also will geotag geospatial outputs.
Specifically, when calling the getRegion function or endpoint, if an encoding of TILED is used (previously this could have been one of JPEG, PNG, or TIFF), a tiled tiff is output.  For non-geospatial sources, this is tiled using vips.  For geospatial sources, this is tiled using gdal.
When using the TILED option, a variety of parameters that can be used in conversions can be used: compression, quality.  For compatibility, these can also be tiffCompression and jpegQuality.

This resolves #567.  It handles metadata for geospatial sources, but doesn't include scale for non-geospatial sources yet.

When getting a tiled region of a geospatial source without any styling, this uses gdal.Warp to create the region.  This code path preserves semantic information in the data, such as categorical mappings.


fixed Item instantiation error in Pytest 8

Changed finalizer to use a dummy Class to avoid ABC instantiation error
Pytest made this change in version 8.0 to enforce standards for their base classes
Added tests to validate fixture handling at class and module scope
I find the chance of a name collision highly unlikely, but if requested I will add a note to the documentation instructing users to avoid naming any of their test classes 'Fakeboi' while using pytest-retry. I hope common sense will prevail.

Thanks to @adamtheturtle for highlighting this change and pushing an initial fix!

@adamtheturtle As far as I can tell this fix is functionally identical to the one you proposed in https://github.com/str0zzapreti/pytest-retry/pull/34. I experimented with a couple of other Item subclasses including Function and FunctionDefinition but settled on Class as the simplest way to resolve the error while ensuring the necessary fixture scopes are all handled correctly. I prefer this over using Module because it minimizes imports, but otherwise your fix is just as good (ignoring the added tests and comment updates).


C* 3.0 doesn't clean up properly upon shutdown

Shutting down a 3.0 cluster on Windows (currently tested with 3.0.0-rc1) via ccm stop most of the time closes the Java processes, but doesn't remove the cassandra.pid files in the node directories. This causes subsequent starts of the cluster to fail with Exception: Timed out waiting for pid file. Sometimes only a few pid files are removed, leaving at least one, which still causes a failed launch. Other times the Java processes are left alive as well.
In most cases, killing all alive Java processes and removing each pid file in the node directories fixes the issue. However, even if there are no old pids lying around, sometimes it still fails to start (with the above timeout error). Retrying usually works in this case. Regression introduced in C* 3.0, as this was not an issue with C* 2.2.

So I don't believe ccm stop should remove the cassandra.pid files. ccm start removes the old pid right before trying to start the new process. Check out line 530 in node.py

Found the issue. Environmental. Leaving this open, as we need a flag that when set, provides better debug output of windows start failures. Essentially we just need to make it perform the equivalent of this patch:
diff --git a/ccmlib/node.py b/ccmlib/node.py
index cd5ade1..3b4e068 100644
--- a/ccmlib/node.py
+++ b/ccmlib/node.py
@@ -535,11 +535,15 @@ class Node(object):
             # clean up any old dirty_pid files from prior runs
             if (os.path.isfile(self.get_path() + "/dirty_pid.tmp")):
                 os.remove(self.get_path() + "/dirty_pid.tmp")
-            process = subprocess.Popen(args, cwd=self.get_bin_dir(), env=env, stdout=FNULL, stderr=subprocess.PIPE)
+            process = subprocess.Popen(args, cwd=self.get_bin_dir(), env=env, stdout=subprocess.PIPE, stderr=subprocess.PIPE)
         else:
             process = subprocess.Popen(args, env=env, stdout=FNULL, stderr=subprocess.PIPE)
         # Our modified batch file writes a dirty output with more than just the pid - clean it to get in parity
         # with *nix operation here.
+
+        stdout, stderr = process.communicate()
+        print stdout
+        print stderr
         if common.is_win():
             self.__clean_win_pid()
             self._update_pid(process)

Issue related to using the wrong JDK (jdk7) while attempting to start C* 3.0. Using JDK8 fixed the issue.


README.md typo

The README.md has this line:
g.arc(x=10, y=5, radius=20, direction='CCW')  # counterclockwise arc with a radius of 5
Isn't that a counterclockwise arc, ending at x=10, y=5 with a radius of 20?

Fixed in #54
Thanks for catching that!


how to use the newest 3.0 AFNetworking?

I saw a lot of e.g. on website to tell how to migrate oc to swift using af2.0, but for 3.0, not enough, I have no idea how to use it to get some feedback from a url I gave

Hi @purifier1990,
Questions like these are best suited for Stack Overflow. We use Github to report issues and feature requests for the library, so we can focus on improving it.
Cheers :beers:


Made a portfolio website

Issue #32
Made a simple portfolio website using HTML,CSS.
Please accept my PR under Hacktoberfest.

image not found, can you try make it more attractive add some css


Will work only for playlist with at most 100 tracks

Describe the bug
SpotiSharp will retrieve only first 100 tracks from a playlist which might have more than 100. The reason is Spotify API pagination and I think it should be added (maybe using PaginateAll from SpotifyAPI.Web)
How To Reproduce
Any playlist with more than 100 tracks
Desktop (please complete the following information):

Windows 10
build 10.0.19042

Definitely i'll have to look into it.
Here is a workaround which can be used until solution is found.
In spotify application you can select tracks with ctrl.
Just like in any file manager application you can copy and paste them to newly created playlist using keyboard shortcuts.
Make 2 temporary playlists and split tracks between them.

Added pagination and it seems to work correctly
I have to make few checks before releasing it.

Definitely i'll have to look into it.
Here is a workaround which can be used until solution is found.
In spotify application you can select tracks with ctrl.
Just like in any file manager application you can copy and paste them to newly created playlist using keyboard shortcuts.
Make 2 temporary playlists and split tracks between them.

Already did that, thanks for suggestion. I am mostly interested to see how you implemented pagination (I tried myself to do it on your code with with no luck)

Here is solution:

It won't stop :)

Thanks a lot

I considered this issue as solved. If any issues occurs feel free to re-open this issue.
Also don't forget to leave a star if you like SpotiSharp so others can find this repository :)


Filter tasks - Download CSV

We need to provide a way to download the complete list of search results in CSV format for all filters

YES PLEASE!

This would likely be implemented as Download. Has to be asynchronous much like dwc occurrences download works now.

it would be even better the customized columns list. thanks

Done for:

[x] Otu
[ ] CollectionObject
[ ] CollectingEvent
[ ] TaxonName

great! Thanks @mjy


Show altair plot in embedded webbrowser

I found this snippet to show any html in the Qt browser window:
https://stackoverflow.com/questions/64164738/how-to-embed-basic-html-page-using-qt
Can we use this to show the altair plots in a new window?

Can also be used to show the dashboard in its own window.

I've been experimenting with this on the Gateway, but I seem to be stuck in some sort of dependency hell, because we have no way of installing/updating system libraries. PySide2 needs Qt5, which is tricky to install and not worth the hassle. Which is a shame, because it works perfectly on my system otherwise. Not sure if it is worth the effort adding this over just installing a modern version of firefox.