No standup, Damian menciona que talvez as coisas relacionadas ao Nuget se movam para algo que será um substituto para o packages.config atual. Obviamente, essas decisões são um caminho justo no futuro, eu duvido que você obtenha quaisquer respostas concretas neste momento.

E não concordo que "JSON é muito mais simples de representar essas dependências". Há prós e contras. Veja https://gist.github.com/darrelmiller/07fed784d2c20de9f5d3719977167181

Eu concordo com a mudança _if_ estava mudando para nuget.json. essa é a única parte do project.Json que achei que precisava ser editável pelo desenvolvedor de qualquer maneira.

@darrelmiller Yaml é provavelmente uma alternativa ainda melhor em termos de verbosidade. E você trapaceou com a string separada por vírgulas em vez de matrizes;).

@sandorfr Pois é. No entanto, suspeito que uma das razões para voltar a um sistema de projeto baseado em XML é por causa das ferramentas significativas existentes em torno de sistemas de projeto baseados em XML no ecossistema .net. Meus comentários não são para tentar identificar o melhor formato, apenas para apontar que XML não é intrinsecamente ruim.

Sim, e essa é a pior notícia desta semana. É como voltar no tempo ... :( Na verdade, o Xml não é ruim, mas o msbuild ... E um projeto base do msbuild xml não será tão bom quanto você descreveu.

No entanto, suspeito que uma das razões para voltar a um sistema de projeto baseado em XML é por causa das ferramentas significativas existentes em torno de sistemas de projeto baseados em XML no ecossistema .net.

Eu simplesmente não entendo por que todas as coisas foram sufixadas com " core " para indicar que é uma coisa totalmente nova se a intenção é também levar a bagagem adiante como o msbuild.

O processo tem sido muito doloroso por mais de dois anos, mas muitas pessoas estavam bem porque todas as novas adições e melhorias estavam alinhando o ecossistema com outros ecossistemas e todos eles eram mudanças por bons motivos. No entanto, de repente, os desenvolvedores corporativos de matéria escura começaram a dar feedback por trás das portas fechadas e estamos vendo muita bagagem sendo carregada.

Não há muitos ecossistemas por aí com configuração baseada em XML. Na verdade, todos os novos ecossistemas projetados estão adotando outros formatos (YAML, JSON, etc.). Veja a reação de todas as pessoas nas redes sociais, não vejo muitas pessoas que gostem dessa mudança. No entanto, o feedback fornecido em particular parece mais importante para a equipe. Isso não é uma coisa ruim, eu entendo os motivos, mas está apenas mostrando como as decisões estão sendo processadas neste ecossistema.

+1 nas piores notícias da semana. Onde estava a discussão sobre isso? Não consigo encontrar nada, apenas uma decisão unilateral.

Não vejo nenhum apoio da comunidade para esta decisão, e muito contra (85% a 15% na última contagem). Como foi a discussão, quem tomou a decisão, com base em quais informações?

É assim que fazemos as coisas no .NET Core? Comprometer a qualidade atrás de portas fechadas porque queremos oferecer suporte a uma lista não divulgada de tecnologia legada?

Com certeza, vamos fazer uma extensão VS que cria um .csproj a partir de um project.json que as pessoas que usam essas tecnologias antigas podem fazer uso.

Mas não nos mande de volta ao pesadelo dos arquivos de projeto baseados em XML. Eles não foram uma boa ideia quando foram introduzidos, e há mais de uma década pagamos o imposto de mesclagens ruins e legibilidade difícil. É o suficiente.

Acho que você está sendo muito pessimista - e acho que é principalmente porque todos nós ficamos surpresos com isso. Deixe-os compartilhar mais informações sobre seus planos e então veremos. @DamianEdwards disse claramente que deseja manter as partes boas do modelo project.json.

Na minha opinião isso seria:

• não ter que especificar cada arquivo cs
• ser capaz de modificar o arquivo sem ter que descarregar o projeto
• ser capaz de modificar dependências do nuget diretamente no arquivo (com IntelliSense)
• ser capaz de substituir pacotes nuget por fonte local por meio de global.json

Em termos de compilação, só acho que deveria ser possível compilá-lo sem ter o Visual Studio instalado. Para mim, não importa se o comando real é "dotnet build" ou "msbuild". O importante é que deve haver uma forma de compilar toda a solução, que - aliás - ainda não existe em "dotnet cli" (pelo menos não que eu saiba).

Se isso puder ser feito, estou ok com a sintaxe que eles usam. XML não é ótimo, mas JSON também tem suas desvantagens.

Edit: Acho que isso não muda nenhuma das ideias fundamentais (e excelentes) do .NET Core etc.

IMHO, o principal problema é que esses tipos de mudanças drásticas pouco antes de RTM não é bom. Se isso acontecer em tempos de beta, os desenvolvedores / equipes não ficarão muito surpresos. Pense nos investimentos que as pessoas estão fazendo desde os últimos 2 anos . Pense nos produtos / bibliotecas / estruturas atuais, dependendo do sistema project.json . Asp.Net está em RC, não em preview / alpha / beta, esse tipo de mudança quebra a confiança dos desenvolvedores / equipes :(.

IMHO, o principal problema é que esses tipos de mudanças drásticas pouco antes de RTM não é bom.

Eu também pensei no início, mas pelo que entendi, isso não resultará em nenhuma alteração no código do seu aplicativo. Isso afetará apenas seus arquivos project.json / xproj / csproj e eles disseram que a mudança pode ser automática - então isso será semelhante às boas e antigas etapas de migração de projeto que já aconteceram muitas vezes quando você atualizou o Visual Studio.

BTW, eu sempre pensei que ter um project.json e um arquivo xproj (que contém o namespace padrão para os modelos do Visual Studio e alguns caminhos de saída, então você também tem que editá-lo às vezes) era estranho.

BTW, eu sempre pensei que ter um project.json e um arquivo xproj (que contém o namespace padrão para os modelos do Visual Studio e alguns caminhos de saída, então você também tem que editá-lo às vezes) era estranho.

Talvez seja estranho, mas eles respondem a coisas diferentes project.json é o único arquivo necessário para construir um projeto principal .net e xproj está relacionado a ferramentas proprietárias, também conhecidas como estúdio visual. É muito semelhante com package.json e .idea se você usar webstorm para trabalhar em seus projetos de nó. Apenas separação de preocupações. O Visual Studio pode ocultar project.json em Propriedades, se quiser, e oferecer uma experiência GUI com curadoria mesclada, se quiser, sem misturar tudo.

Eu tenho usado essas coisas em um mac no VS Code por tanto tempo que esqueci completamente sobre o xproj. OTOH, eu realmente senti falta da depuração e um pouco mais do Visual Studio!

Acho que você está sendo muito pessimista - e acho que é principalmente porque todos nós ficamos surpresos com isso

Não, desculpe, não acredito que estou sendo muito pessimista. XML é um formato ruim para qualquer situação em que você fará mesclagens de código, ou seja, todos os projetos de software. XML não foi projetado para coisas como arquivos de configuração e arquivos de projeto e nunca deveria ter sido usado para eles. .NET apenas teve o azar de ser construído de volta quando todos pensavam que XML poderia resolver tudo.

http://c2.com/cgi/wiki?XmlSucks
http://www.ibm.com/developerworks/xml/library/x-sbxml/index.html
http://nothing-more.blogspot.co.za/2004/10/where-xml-goes-astray.html

Agora, o .NET Core está sendo construído quando todos pensam que JSON resolverá tudo. Não acredito que JSON seja mais uma solução de longo prazo do que XML, mas sei que é mais fácil mesclar conflitos JSON do que XML.

Tenho achado uma lufada de ar fresco por não lidar com lixo XML para arquivos de projeto, achei mais fácil ler os arquivos JSON, achei os arquivos JSON mais fáceis de trabalhar fora do Visual Studio e eu não quero voltar para XML / MSBuild.

Sim, esses são meus sentimentos pessoais e, sim, são subjetivos, mas com base nos comentários no Twitter e em outros lugares, não acredito que estejam isolados. Para ser honesto, essa decisão está me fazendo duvidar completamente de toda a direção do .NET Core, e mais especialmente da maneira como decisões importantes como essa são tomadas.

@DamianEdwards disse claramente que deseja manter as partes boas do modelo project.json.

Da minha perspectiva, as melhores partes do modelo project.json são que ele não é csproj, nem MSBuild, nem XML. Essas partes "boas" serão mantidas? Aparentemente não. Depois que fomos levados a acreditar que eles estavam finalmente sendo turfados, descobrimos que era tudo mal-entendido. Fomos informados sobre o novo sistema de compilação, sobre Gulp e project.json e como as coisas seriam diferentes agora, e então descobrimos que era tudo uma farsa e era uma porcaria do velho MSBuild de novo.

Acho que os formatos JSON e XML são praticamente os mesmos em termos de mesclagem - ambos têm tags de fechamento (embora seja apenas uma chave em JSON), o que significa que você tem problemas com cenários vazio / um / muitos. Basta alterar um array JSON vazio para um com itens. Eu diria que JSON ainda tem a desvantagem adicional da vírgula final, que muda duas linhas se você adicionar um item a uma lista.

Você teria que mudar para YAML, etc, se quiser evitar isso.

IMO, o problema com csproj não é com XML, mas como o Visual Studio o tratou e que continha todos os arquivos cs. Se isso for corrigido e as ferramentas não mudarem coisas aleatoriamente no arquivo, a fusão não será mais um problema.

No entanto, em termos de legibilidade, também prefiro JSON. Consegui escrever um project.json do zero - acho que não poderei mais fazer isso com o csproj (csproj requer um ProjectGuid aleatório, etc.). Portanto, definitivamente precisaremos de suporte a ferramentas / linha de comando para isso.

Minha principal preocupação sobre essa coisa toda, sobre a qual não ouvi muito, é que project.json é muito mais declarativo quando se trata de referências do que .csproj arquivos de projeto. A beleza das dependências no arquivo project.json e por que eu estava ansioso para migrar nossa base de código para ele é que você apenas diz "Eu preciso desta dependência" e não importa se é um projeto local ou um Pacote NuGet. Em nosso caso, isso nos compraria muita flexibilidade e novas opções interessantes. Em contraste, atualmente uma referência em um arquivo .csproj é um caminho relativo e rígido para um arquivo .dll no disco. No momento, adicionar uma entrada em seu packages.config em um projeto tradicional não faz nada, você também precisa adicionar uma referência a um .dll desse pacote para o arquivo .csproj . Isso é feito para você pelas ferramentas NuGet dentro do Visual Studio, mas não quero usar essas ferramentas quando adicionar uma linha de texto a um arquivo project.json é muito mais simples.

Eu reconheço que a equipe deseja manter todas as funcionalidades fornecidas pelo arquivo project.json e expandir os recursos do formato .csproj , mas eles também conversaram sobre como manter project.json como um arquivo para especificar seus pacotes NuGet. Não vejo o que isso adicionaria em comparação com a situação atual com packages.config onde apenas adicionar uma entrada a ele não é suficiente porque você ainda precisa adicionar uma referência a .dll em .csproj também. Se o arquivo .csproj se tornar o futuro, prefiro muito mais ver a equipe principal ir até o fim e descartar project.json ou nuget.json ou, no entanto, ele acaba sendo chamado de _totalmente_ e adiciona uma maneira mais declarativa de adicionar referências ao formato .csproj . Posso viver muito bem tendo que editar um arquivo XML em vez de um arquivo JSON (embora eu certamente prefira JSON), mas seria uma pena perder a natureza declarativa de project.json e eu não preciso de dois diferentes lugares onde preciso especificar minhas dependências.

Envie feedback em https://www.surveymonkey.com/r/H6Q88PP

Só para ficar claro, ao ler as notas do Standup, ele menciona que uma opção é ter uma opção de instalação do nuget --save (consulte https://blogs.msdn.microsoft.com/webdev/2016/05/11/ notes-from-the-asp-net-community-standup-may-10-2016 /). Embora eu ache que é uma boa ideia, substituir o 'arquivo de edição .json com intellisense' por isso, acho uma má ideia. Acho que ficar no editor é uma boa ideia para alguns de nós que não querem mudar para um shell para fazer tudo. Minha preferência, pessoalmente, é ter as duas experiências. linha de comando + IU para adicionar dependências não são bons o suficiente.

Eu sou um codificador, não quero sair do editor.

Acho que é uma decisão horrível. Vocês disseram que queriam tornar o .NET Core realmente simples, mas depois fizeram essa alteração. Eu não me importo com a quantidade de batom que você coloca no MSBuild, ele ainda será o MSBuild e as pessoas de fora vão olhar para ele e ser imediatamente desligado. Nunca será um formato simples editável à mão. Talvez tenha havido alguns problemas técnicos difíceis, mas parece que eles estavam relacionados à tentativa de transformar o sistema de projeto em mais do que apenas um sistema de projeto simples. Se as pessoas quiserem fazer coisas mais complexas em suas compilações, podem escrever alguns scripts ou usar o msbuild para fazer isso. project.json é uma coisa lindamente simples e estou realmente chateado agora.

Minha frase favorita sobre arquivos MSBUILD?

Recentemente, passei muito tempo com arquivos csproj. Eles se parecem e se comportam bastante como o Ant / Maven. Este não é um ponto a favor deles.
Ant / Maven era amado e posteriormente odiado por muitos desenvolvedores Java. XML é uma sintaxe extremamente detalhada com a qual devemos lidar.
Mas o verdadeiro assassino é o lockin. Sim, você pode usar o msbuild para fazer coisas com eles, mas a sintaxe é realmente projetada não para um desenvolvedor ler / editar, mas para um IDE para serializar o estado. Só porque há um executor de linha de comando não significa que o formato seja amigável para o desenvolvedor. Enquanto você permanecer no VS, você realmente não notará. Assim que você sair, não será mais confortável. Arquivos csproj são algo que eu gostaria que .Net tivesse seguido um caminho diferente de java em.

Fonte

Acho que é importante fazer uma distinção entre o MSBuild e a maneira como o Visual Studio usa atualmente o MSBuild. Há anos edito manualmente arquivos MSBuild e os uso em todos os meus projetos. Por exemplo, https://github.com/tavis-software/Tavis.home/blob/master/build/Build.proj

Os arquivos csproj que o Visual Studio cria são muito desagradáveis, mas culpar o MSBuild é como dizer que C # é uma porcaria porque você viu um gerador de código criar um código feio com ele uma vez.

@darrelmiller eu concordo.

Vamos adiantar 6 meses e ver se é um momento "avisei" ou mais de um "esquivei uma bala".

Seguindo a ligação de @shawnwildermuth em seu blog , vou jogar meus próprios 2 centavos:

Não vejo por que isso é tão importante. Estou feliz em voltar para um csproj baseado em XML, porque:

• Editar JSON manualmente NÃO é mais natural / fácil do que XML. Na verdade, é o oposto IMHO. Todo editor estúpido me dá preenchimento de tag XML, localizar um erro de formato manualmente é mais fácil e assim por diante. JSON não é mais fácil se eu tiver que escrever manualmente. Dizendo isso me leva ao ponto 2 ...
• Em primeiro lugar, por que existe tanto barulho sobre a edição de um arquivo de projeto com um editor? A edição de um arquivo de projeto NÃO é onde desejo gastar meu tempo como desenvolvedor. Isso deve ser algo pontual no início de um novo projeto, mas depois disso não deve acontecer com muita frequência IMHO. Se eu tiver que editar com JSON, XML, YAML, TOML ou o que quer que alguém goste naquele momento, é completamente irrelevante para mim.
• A única coisa que eu gostaria de evitar é acoplar o NuGet ao ASP.NET . NuGet é ótimo, eu adoro isso e quero que meu ASP.NET funcione muito bem com ele, mas NÃO é necessário para executar o ASP.NET. Sim, posso precisar extrair os binários de um feed NuGet para obter os recursos do MVC, etc., mas se eu fizer isso por meio do feed NuGet oficial ou se eu puxar os fontes, compilar localmente e copiar e colar em um pasta deve ser uma flexibilidade que permanece disponível para mim. Não quero que o ASP.NET, o csproj ou qualquer outra coisa seja fortemente acoplado a esses sistemas de "suporte" de terceiros. Quero que eles permitam uma ótima integração, mas mantenha a porta aberta para customização ! Portanto, espero que os pacotes NuGet não sejam declarados no arquivo .csproj e que um nuget.json não seja totalmente integrado ao MSBuild.
  Integração perfeita por trás de uma interface bem definida == ÓTIMA.
  Acoplamento rígido, assumindo que este seja o padrão para todos == RUIM.
• Por último, quero dizer que project.json tem muito pouco a ver com .NET Core e ASP.NET Core. O Core tem muito mais a oferecer do que um arquivo project.json. Project.json não era um recurso novo, era uma tentativa de redesenhar algo que já existia em um formato diferente. Não me importo muito com isso, porque, como desenvolvedor, prefiro focar nos novos recursos e possibilidades fornecidos pelo .NET Core para desenvolver um ótimo aplicativo na nuvem, em vez da configuração enfadonha que tenho que fazer de vez em quando.

Acho que é uma grande mudança voltar para o MSBuild, porque, como desenvolvedor, me preocupo mais com a compatibilidade e acho que essa é a chave. O MSBuild funciona e, para ser justo, funciona muito bem na maior parte e em vez de substituí-lo por algo novo, o que traz novos problemas e causa problemas de compatibilidade, prefiro que alguém melhore o que já funciona e o torne melhor com o tempo. Todo mundo pensa que pode reescrever as coisas e torná-las melhores, até que você percebe que só resolveu um pequeno problema, que era importante para você naquele momento e, mais tarde, quando você deseja expandir, você se encontra reconstruindo a mesma coisa que você tentou substituir no início. Melhor melhorar as coisas que já funcionam.

É também por isso que provavelmente teria preferido tornar o Mono melhor e fechar as lacunas em vez de implementar um novo tempo de execução de plataforma cruzada, mas essa é uma discussão diferente.

Resultados finais da pesquisa: 100 respostas, para uma população de desenvolvedores .NET de 9 milhões de ± 10% com 95% de confiança.

Gostou da mudança para project.json?
Sim, foi um dos meus recursos mais esperados 19,19%
Sim 39,39%
Não 13,13%
Não, foi uma direção terrível tomar 16,16%

Você está feliz em voltar para o MSBuild?
Sim, agora posso pensar em adotar 9,09%
Sim 16,16%
Não 30,30%
Não, isso me faz questionar a direção que o .NET Core está tomando 29,29%
Não me importo 15,15%

Você acredita que o MSBuild será melhorado
Melhorado? Já está perfeito. 1,01%
Sim 63,64%
Não 12,12%
Está fundamentalmente quebrado, como pode ser melhorado? 20,20%
Não me importo 3,03%

Você acha que esta decisão foi tomada corretamente?
Sim, a equipe recebeu feedback a bordo e mudou de direção quando teve de 20,41%
Sim 6,12%
Não 24,49%
Não, a equipe tomou decisões irresponsáveis, a portas fechadas, sem envolver a comunidade 39,80%
Não me importo 9,18%

Como essa decisão afeta sua percepção do .NET Core?
Melhora, eles finalmente estão voltando à sanidade 13,00%
Melhora 11,00%
Piora 42,00%
Piora, me faz questionar tudo 18,00%
Não me importo 16%

100 pessoas fizeram a pesquisa. Eu nem sabia sobre isso até agora. Vamos olhar de novo quando tivermos números representativos, porque 100 pessoas é uma piada de mau gosto, no máximo.

Na verdade, conforme indicado, 100 pessoas fornecem uma margem de erro de ± 10% com 95% de confiança. Que nível de confiança você precisaria para ver que está vendo um reflexo verdadeiro? Devemos pesquisar todos os 9 milhões de desenvolvedores?

Os 800 votos no UserVoice para estender o project.json ao resto do VS também não mostram a tendência?

E se vamos fazer uma amostra verdadeiramente representativa, então talvez a Microsoft deva fazê-lo. Uma vez que eles não pediram depois de repetidas reclamações de várias direções.

Eles terão um alcance muito melhor do que eu, fazendo uma pesquisa privada. Eu precisaria atualizar meu plano da SurveyMonkey para acessar mais de 100 resultados, a um custo para mim, para que eu pudesse executar uma pesquisa que a própria Microsoft deveria ter feito!

Bem, se você deseja ter números significativos, deve ter como objetivo uma representação justa dos 9 milhões de desenvolvedores. Se eu tiver 100 seguidores no Twitter, que me seguem porque compartilhamos o mesmo interesse e peço a todos que respondam à pesquisa, então você terá 100 pessoas com uma visão unilateral, representando apenas um determinado grupo de desenvolvedores.

A justificativa dada no standup para ressuscitar o MSBUILD foi tornar possível a integração entre as ferramentas existentes e mais fácil para os projetos existentes fazerem uso do .NET core. No entanto, depois de migrar um projeto bastante grande para o .NET core, para ser honesto, o sistema de projeto foi o MENOS dos meus desafios. Portanto, usar isso como única justificativa não parece um grande motivo para mim. Também trabalhei durante anos com o sistema csproj, incluindo a edição manual de arquivos. Isso sempre foi doloroso. O sistema baseado em project.json é MUITO mais simples e muito mais acessível por todos (incluindo iniciantes). Eu acho que esse é o objetivo. E agora estamos dando um passo para trás ao ressuscitar o MSBUILD. Minha opinião pessoal é que isso é um grande erro. Eu coloquei meu voto em manter o project.json.

Na verdade, quase não tenho seguidores no Twitter; em grande parte, são seguidores de desenvolvedores do .NET Core cujos streams do Twitter eu postei.

E, novamente, certamente a pessoa certa para fazer essa pesquisa seria a Microsoft? Por que sobrou para mim ser o único a realmente perguntar às pessoas o que elas querem?

Por que a MS não dá a mínima para o que as pessoas pensam?

TBH Não sabia que havia uma pesquisa até 30 minutos atrás e não sabia que você está fazendo a pesquisa de forma privada. Eu concordo ... se a Microsoft tiver interesse na reação do desenvolvedor a essa mudança, eles deveriam fazer essa pesquisa. Mas talvez eles já tenham feito o dever de casa e é por isso que estão fazendo essa mudança. Eu não sei, mas eu nem sempre veria as coisas tão negativamente, porque afinal esses caras estão construindo essas coisas para nós, então eu tenho certeza que eles têm apenas o melhor interesse para nós.

Se eles tivessem feito sua lição de casa, eles saberiam que 60% dos desenvolvedores eram contra esse movimento e teriam se comunicado e se engajado de acordo. Eles não o fizeram, o que significa que não tinham ideia da reação, o que significa que não se envolveram.

Sou um cliente pagante de licenças corporativas para VS. Não vi nada. Eu trabalho em quatro empresas de fins de serviços de primeira linha, também pagando clientes corporativos. Eles não viram nada. Então, quem exatamente eles se envolver com? Tenho feito essa pergunta desde a noite passada e não recebi nenhuma resposta sobre ela.

Estou vendo as coisas negativamente porque esta é uma mudança enorme e de última hora em uma parte fundamental da história do .NET Core, uma parte que nos foi comunicada como sendo fundamental para o futuro, e nós (talvez estupidamente) os levamos em sua word, e construímos um pipeline de CD / CI com base nessa tecnologia que agora é totalmente inútil. Também estou vendo isso de forma negativa, porque em um dia inteiro de pedidos de detalhes sobre a tomada de decisão houve um silêncio absoluto no rádio.

Pelo que ouvi, parece que eles colocaram os usuários sob o ônibus para ajudar os fabricantes de ferramentas. Em caso afirmativo, eles podem cobrar minhas taxas de licença do VS dos fabricantes de ferramentas, e não de mim.

@shederman Embora eu concorde com os resultados de sua pesquisa, suas perguntas obviamente apontam para a direção preferencial de permanecer no formato json, e isso não a torna realmente uma boa pesquisa. Eu levei isso para me divertir e não levaria os resultados a sério (desculpe). Eu me pergunto por que não podemos ter os dois - torná-lo opcional de uma forma ou de outra, porque não sou fã do msbuild ou de outras coisas. Eu amo json, é meu amigo.

Eu concordo com você que não é uma pesquisa ideal. Eu o criei no espaço de 5 minutos. a questão é: por que estou criando?

Por que a Microsoft não está interessada em descobrir o que as pessoas pensam?

Eu esperava apenas cerca de 30 respostas e esperava que fosse o suficiente para convencê-los a reabrir a discussão, compartilhar seus pensamentos abertamente e se envolver conosco de maneira adequada, em vez de passar por cima de opiniões.

Agora está em 138 respostas, mas ainda não há sinal da Microsoft, mesmo considerando que talvez sua decisão tenha sido ruim. Apenas explicações vagas acenando com a mão não apoiadas pelos fatos.

Tudo que eu quero é um engajamento adequado nesta decisão. Não são decisões importantes tomadas a portas fechadas com base em informações secretas e feedback. Deve ser feito de forma aberta e com transparência, palavra que tem faltado singularmente neste processo.

Oh rapazes, vamos. A Microsoft é dona do framework e permite que ele faça o que quiser. Mas pense por um momento, as pessoas estão trabalhando nisso desde março-abril de 2014 e pouco antes de 1 mês do lançamento, fazer esse tipo de mudança dramática é ridículo. Isso quebra a confiança dos desenvolvedores. É uma perda de tempo das pessoas. Não há necessidade de fazer uma estrutura de código aberto se você não pode confiar na comunidade. Vá e feche a fonte imediatamente para que ninguém o incomode quando você fizer esse tipo de mudança nas salas escuras.

Peço desculpas e simpatia pela Microsoft (MVPs ou membros da comunidade), por favor, sejam realistas neste momento.

@shederman

Se eles tivessem feito sua lição de casa, eles saberiam que 60% dos desenvolvedores eram contra essa mudança,

Ficaria surpreso se mais de 20% dos desenvolvedores no ecossistema .net soubessem da existência de project.json. Às vezes esquecemos que vivemos em uma espécie de bolha de desenvolvedores, cavalgando na vanguarda dos novos desenvolvimentos tecnológicos.

Acredito que muito do apelo de project.json é sua simplicidade. No entanto, se você tem acompanhado seu desenvolvimento desde que foi introduzido pela primeira vez no ASP Net Insiders há 3 anos, ele começou a acumular mais complexidade à medida que tenta oferecer suporte a mais casos de uso. Para dar suporte a todo o ecossistema .net, temo que muito da amada simplicidade seria perdida.

Isso não quer dizer que project.json não traz alguns novos recursos incríveis, e eu acredito que tornar o formato do projeto mais acessível para humanos é uma coisa boa. No entanto, acho que trazer essa bondade para o MSBuild é mais viável e beneficiará muito mais pessoas antes de tentar trazer o project.json para todos os lugares.

Ficaria surpreso se mais de 20% dos desenvolvedores no ecossistema .net soubessem da existência de project.json.

Aposto que menos de 20% dos desenvolvedores em .net eco conhecem MVC e Web Api. Mais de 70 pessoas estão usando WebForms, WCF, WebService. Mais uma vez, peço um apologista e simpatia da Microsoft, por favor, seja realista

@shederman Seu relatório de qualquer confiança a partir dos resultados de sua pesquisa provavelmente está incorreto para a população de desenvolvedores .NET em geral, e pode nem mesmo ser uma boa amostra representativa de ... "esses são em grande parte seguidores de desenvolvedores .NET Core cujos streams do Twitter eu postei. " Sua amostra não é

Nenhuma conclusão estatística útil pode ser tirada com base em sua pesquisa para a população como um todo. No entanto, estou feliz por você ter feito a pesquisa. Você apresenta muitos pontos excelentes. Acho que os resultados indicam que muitas pessoas estão chateadas ou preocupadas com a mudança. No entanto, por favor, não publique conclusões estatísticas falsas ... divulgando números que são virtualmente sem sentido e fazendo comentários ultrajantes como "eles sabiam que 60% dos desenvolvedores eram contra esse movimento."

Então, de que adianta mudar alguma coisa se vamos incomodar mais de 70% da base de mercado? Vamos ficar exatamente onde estamos e continuar fazendo evolução incremental. Se não está quebrado, não conserte, certo?

Eu sei que project.json acumulou complexidade. Concordo 100% nesse ponto. A solução foi voltar ao csproj? Eu disse às pessoas antes que estou totalmente atrás da Microsoft por fazer as coisas certas, em vez de enviá-las com pressa. A mudança para o csproj parece apressada.

Por que fazer isso depois do RC2? De onde veio isso? A aquisição da Xamarin teve algo a ver com isso? Foi a integração de dotnet-cli ? Foi um grande cliente? Quem sabe...

Eu poderia explicar às massas que RC1 -> RC2 era o melhor. Unificado com o dotnet cli. Mas a mudança project.json? Não tenho nada a dizer para explicar isso. Só que não sei. As pessoas estão confusas e não tenho argumentos convincentes para elas.

Por que fazer isso depois do RC2? De onde veio isso? A aquisição da Xamarin teve algo a ver com isso? Foi a integração dotnet-cli? Foi um grande cliente? Quem sabe...

Este é o ponto pensado. Não sabemos toda a história por trás da mudança para o csproj. Agora, em vez de se recostar, relaxar, observar e entender por que isso está acontecendo, todos estão xingando a Microsoft e presumindo o pior. Isso não faz sentido. Esses caras estão construindo essas coisas para nós e apenas para nós. Definitivamente, eles não fazem essas mudanças por causa de um grande cliente, porque um grande cliente não vale a pena se você correr o risco de perder toda a sua comunidade. O ecossistema Microsoft .NET é ENORME e fazer o .NET Core se encaixar bem nele é obviamente uma tarefa complexa, então eu sugiro que todos relaxem um pouco e presuma que esses caras têm algumas pessoas inteligentes por trás dele, tomando as decisões certas para que podemos nos beneficiar ao máximo - longo prazo. Estou fora daqui, porque toda essa especulação prematura negativa está me entediando.

@darrelmiller Desculpe, quando digo 60%, quero dizer 60% daqueles que responderam à pesquisa.

@GuardRex Você está absolutamente certo. A única organização que pode nos dar resultados adequados é a MS, e eles não parecem se importar.

Minha pesquisa pretendia simplesmente avaliar um nível vago de apoio, não fornecer uma amostra estatisticamente significativa. Acredito ter mostrado que há infelicidade suficiente para abrir esta decisão, mas parece que a Microsoft não concorda, bem, se o silêncio do rádio deles é uma indicação.

Aqui está a pergunta: o que exatamente seria necessário para que a MS admitisse que talvez cometeu um erro? O que seria necessário para fazê-los reabrir a discussão? Porque neste momento parece que a resposta é "não nos importamos com o seu ponto de vista, nossa decisão permanece e não vamos compartilhar as razões"

Eu sugeriria que todos relaxassem um pouco e presumissem que esses caras têm algumas pessoas inteligentes por trás disso, tomando as decisões certas para que possamos nos beneficiar ao máximo - longo prazo

Isso é o que eu disse para torná-lo um código-fonte fechado, porque as pessoas inteligentes por trás disso estão sempre certas e a comunidade de código aberto é tola.

@shederman "para não fornecer uma amostra estatisticamente significativa" ... tudo bem, mas gostaria que você apenas deixasse a pesquisa se

Resultados finais da pesquisa: 100 respostas, para uma população de desenvolvedores .NET de 9 milhões de ± 10% com 95% de confiança.

Essa é a parte que fica realmente arriscada. Pode ser verdade que 60% dos desenvolvedores .NET odeiem ou não gostem dessa mudança; no entanto, você não pode mostrá-lo com esse exemplo. Vamos apenas dizer, sim, muitos desenvolvedores têm uma grande preocupação com a mudança e a forma como ela foi tratada. Isso está claro, e a pesquisa realmente destaca bem esse ponto.

@abcplex : Código aberto não significa que você tem que pular toda vez que 16 pessoas abrirem um problema no GitHub e gritar pular.

@MaximRouiller O Standup Notes explica muito bem a motivação para as mudanças. E a realidade, pelo que li, é que xproj está sendo substituído por csproj e project.json provavelmente será renomeado como nuget.json e _algumas_ coisas serão removidas de project.json.

E pelos comentários feitos no standup, essa foi uma decisão bem recente, a comunidade foi informada quase imediatamente, o project.json não vai a lugar nenhum até depois do RTM, então as mudanças podem acontecer novamente.

Para mim, este parece ser o processo mais inclusivo e transparente que poderia ter acontecido.

@darrelmiller Isso, vou ter que concordar com você. Muito transparente.

Se eles queriam feedback, acho que conseguiram. Em qualquer caso, não há como lutar contra isso. As pessoas falaram. A Microsoft ouviu. Vamos ver se eles podem fazer algo sobre isso ou se estão de mãos atadas.

Só o tempo nos dirá agora.

Não creio que o problema seja com a transparência. Eles fizeram um trabalho incrível de transparência. Acho que o problema é que eles estão tomando decisões importantes sem saber o que a comunidade pensa sobre isso. Sei que é impossível projetar por comitê, mas talvez eles devessem ter documentado a lista de prós e contras que analisaram e apresentaram à comunidade para algo tão fundamental quanto essa mudança. Esperançosamente, eles postarão esse tipo de informação em breve, mas, mesmo assim, parece que a decisão já foi tomada.

Isso afeta os primeiros usuários mais do que qualquer outra pessoa.

JSON tem uma boa leitura, mas apenas quando é simples. </system> é mais fácil de entender do que ]} na minha opinião.

Os comentários mais razoáveis ​​aqui ecoam meus próprios pensamentos sobre o descarregamento / carregamento de projetos e gerenciamento de dependências que não precisam do detalhamento inerente ao XML.

Deveria realmente ser uma discussão sobre JSON x XML? Realmente não importa IMHO
(claro, pessoalmente, gosto mais de JSON do que XML, mas isso não é importante)

O que eu realmente gosto no ASP.NET Core é que ele é bastante aberto e independente do Visual Studio e de qualquer outro IDE. Se ainda for fornecido, não tenho nenhum problema com esta decisão.

Há muita discussão tóxica acontecendo nesta questão, que eu sinto que está fazendo com que muitas pessoas percam a visão. O argumento geral parece ser "MSBuild é ruim!" mas não há compreensão suficiente do que é bom / ruim em ambas as abordagens.

Para todos que afirmam que isso é um "retrocesso", esteja ciente de que, embora esteja voltando para "csproj", não será o _mesmo_ que os arquivos csproj que tivemos por anos. Por um lado, eles declararam claramente que você não verá uma lista de arquivos no "novo" formato csproj. O principal benefício e o principal motivo pelo qual a maioria das pessoas gostou do formato project.json é não ter essa lista de arquivos.

Imediatamente, essa é uma diferença imediata. Dê uma olhada no xproj hoje e você terá uma ideia do que esperar do "novo" csproj. Será um pouco maior, mas apenas porque terá algumas propriedades extras tiradas de project.json. A verdadeira discussão não é e não deve ser sobre "o quão ruim é o MSBuild", mas o que você deseja ver no novo csproj e o que deseja deixar em um arquivo .json.

@dustinmoris, você é injusto, acho que a maioria das mudanças foi bem-vinda à comunidade, exceto essa. Este está nos levando para trás, e eles já estão falando sobre como farão isso, sem qualquer ideia sobre o porquê. Eles fazem parecer que a decisão é final, então não há lugar para a comunidade apresentar uma proposta melhor.

E sim, nós editamos os arquivos do projeto diretamente e estávamos fazendo isso dolorosamente antes do project.json. Msbuild tem tudo a ver com conhecimento tribal e torna o domínio dele um pouco difícil.

E o "isso vai facilitar a migração de .net 4.5 para .net core" parece um pouco desonesto. Este definitivamente não é o ponto de dor ...

não será o mesmo que os arquivos csproj que temos há anos.

Será XML? Sim, eu pensei assim.

O principal benefício e o principal motivo pelo qual a maioria das pessoas gostou do formato project.json é não ter essa lista de arquivos.

Com base em quais informações você diz isso? Quer dizer, não ter a lista de arquivos é uma grande vantagem, mas de forma alguma a única para mim.

Dê uma olhada no xproj hoje e você terá uma ideia do que esperar do "novo" csproj

Eu não tenho xproj hoje. Por que eu precisaria de uma coisa dessas?

A verdadeira discussão não é e não deve ser sobre "o quão ruim é o MSBuild"

Por que _não_ deve ser essa a discussão? O Turfing MSBuild foi um grande ponto positivo para minha adoção do .NET Core. 20% dos entrevistados em minha (aparentemente) não científica, câmara de eco, pesquisa tendenciosa concordam que ela está fundamentalmente quebrada.

@shederman, sua resposta é exatamente o tipo de discussão tóxica a que estou me referindo. Você está apenas fazendo declarações genéricas (como "MSBuild é ruim!"), Mas não as está apoiando com nenhum tipo de discussão construtiva.

Será XML? Sim, eu pensei assim.

sim. E? Se o seu problema é que você não gosta de _XML_, então é justo. Se você acha que JSON é superior a XML, vá em frente e descreva seus motivos, mas isso não tem nada a ver com a _estrutura do projeto_ e tudo a ver com sintaxe. Infelizmente para você, XML e JSON têm seu lugar no mundo, existem prós e contras distintos para ambos e nunca haverá uma resposta "certa" definitiva sobre qual é o melhor. Novamente, se eu fosse você, me concentraria em quais seriam as diferenças na _estrutura do projeto_ com a mudança.

Com base em quais informações você diz isso? Quer dizer, não ter a lista de arquivos é uma grande vantagem, mas de forma alguma a única para mim.

Nunca afirmei que era o único benefício, simplesmente disse que era, de longe, o _principal_ benefício. Observe qualquer discussão sobre o formato project.json há meses e a primeira coisa que as pessoas falam é como ele é muito menor e mais simples. Não porque JSON seja sintaticamente mais limpo, mas sim a remoção da lista de arquivos do projeto. A maior vantagem que as pessoas mencionam é que ele combina bem e combina bem porque não lista um monte de referências de arquivo nele.

Eu não tenho xproj hoje. Por que eu precisaria de uma coisa dessas?

Toda essa discussão é sobre o novo formato de arquivo do projeto, se você não está disposto a comparar o cenário atual, então sua opinião será mal informada.

Por que não deveria ser essa a discussão? O Turfing MSBuild foi um grande ponto positivo para minha adoção do .NET Core. 20% dos entrevistados em minha (aparentemente) não científica, câmara de eco, pesquisa tendenciosa concordam que ela está fundamentalmente quebrada.

Porque você não está realmente discutindo _MSBuild_, você está discutindo a maneira como o Visual Studio historicamente lidou com projetos MSBuild - que a própria Microsoft admitiu ser pobre. Na verdade, o MSBuild oferece suporte a quase tudo que já é necessário - incluindo não ter que listar todos os arquivos de um projeto.

Mais especificamente, tudo o que você fez até agora nesta discussão foi gritar e gritar que você não gosta de XML, mas ainda não vi você trazer quaisquer argumentos reais a favor ou contra além de "Ele simplesmente não se funde como bem ", que, como afirmei inúmeras vezes, geralmente se reduz à quantidade de arquivos listados em um csproj" antigo ". Se você se preocupasse em olhar para o formato xproj, você veria que é bem pequeno e Daniel disse durante o standup que o "novo" formato csproj teria quase o mesmo tamanho do arquivo project.json atual - então, novamente, o que o problema? Você faz afirmações ousadas, mas não as apóia de forma alguma.

@neoKushan, você logo receberá algum tipo de prêmio da Microsoft por defendê-los sem um bom motivo. Venha para o ponto real de que esta é a pior decisão tomada pelas portas dos fundos. Eu recomendo fazer o asp net close source novamente e permitir que a Microsoft e seus apoiadores como você decidam o que então querem sem perguntar aos membros da comunidade de código aberto

@abcplex Você vai contribuir com alguma coisa para a conversa além de xingamentos e

Até agora, você não fez nada além de reclamar da mudança sem listar um único motivo de qual é o seu problema real com ela.

@neoKushan, o maior ponto é que não é hora para esse tipo de mudança, há apenas um mês para RTM. Fazer essa alteração neste horário não faz sentido.

@abcplex A mudança não está acontecendo na RTM. Será uma mudança gradual pós-RTM . Tudo o que acontece na RTM é que seu xproj é renomeado para csproj - literalmente, nada mais alterações e alterações serão feitas em estágios, com as ferramentas migrando suas alterações para você.

Concorde que JSON vs XML (vs XAML, como no Standup Blog Post algumas pessoas estão pedindo isso) é uma distração do que deveria ser o mérito de ter qualquer tipo de compatibilidade com as ferramentas anteriores.

E eu diria que essa é uma maneira altamente equivocada de pensar. Goste ou não, csproj e MSBuild seguem a tradição do ant, que trata de instruir o conjunto de ferramentas sobre como construir um projeto, em vez de defini-lo. São coisas muito diferentes, mas essa herança parece dar poder de "definição" ao projeto, porque agora podemos aplicar a lógica a ele, e assim por diante. O que isso torna as coisas incrivelmente complicadas.

Com o velho mundo, em várias ocasiões eu vi arquivos de projeto quebrados simplesmente porque uma linha que "precisava estar na parte inferior" foi movida para cima ou alguém mexeu com uma variável de ambiente e de repente estávamos puxando o arquivo .targets errado. A própria noção de que um elemento de primeiro nível (filho da raiz) é dependente da ordem em uma sintaxe declarativa é totalmente quebrada. Essa é a terra do MSBuild e csproj. Esse é o legado que estamos trazendo para cá. Agora, para entender um csproj, é necessário "executá-lo" e executá-lo exatamente como o MSBuild faria. Sim, o MSBuild é de código aberto, mas na verdade não está consertando nada. Ele ainda apresenta uma dependência única e forçada. Ele ainda depende de arquivos de alvos mágicos que ficam ... em algum lugar.

Um arquivo de projeto deve ter várias qualidades que o tornam independente do formato do conjunto de ferramentas que uma determinada loja decide usar:

• Deve ser editável / legível por humanos
• Deve permitir comentários
• Deve ser declarativo
• Deve ser independente
• Deve ser projetado para reduzir conflitos de mesclagem / simplificar a mesclagem, se possível
• Deve ser totalmente documentável (com o princípio de autocontenção se aplicando à documentação)
• Deve ser independente de ferramenta

E o "isso vai facilitar a migração de .net 4.5 para .net core" parece um pouco desonesto. Este definitivamente não é o ponto de dor ...

100% aprovado. Deixe-me esclarecer quais têm sido os desafios para nós: as únicas dificuldades até agora com a migração de bases de código tem sido a perda de certas bibliotecas de classes .NET (olhando para você System.Drawing), reticência por parte das equipes da Microsoft no suporte ao .NET core (olhando para seu Banco de Dados de Documentos) e as mudanças de quebra padrão que podem ser esperadas entre as versões principais.

Em nenhum momento o project.json foi um problema. Na verdade, esse era um dos benefícios. Idem ser capaz de despejar o MSBuild em um detalhe invisível que acontece magicamente quando Ctrl + Shift + B.

@neoKushan

1. Eu não gosto de XML. É um formato ruim para arquivos de projeto e configuração. Foi uma má ideia quando foi introduzido durante a fase "XML para tudo" e é uma má ideia agora.
2. Acho que os arquivos JSON se fundem muito melhor do que os arquivos XML. Aceito que se trate de uma opinião, mas é minha e é baseada nas minhas experiências.
3. Estou usando o vscode que não precisa e não usa arquivos xproj. _Essa_ é a minha paisagem atual, e não quero ou preciso de um arquivo xproj que não signifique nada para mim.
4. Não, estou discutindo o MSBuild. Já fiz muitas coisas com o MSBuild e o Team Build. Eles nunca foram divertidos e nunca foram fáceis e sempre envolveram lutar com o porco na lama. Eu odeio o MSBuild e, com certeza, não estou sozinho.
5. O MSBuild dificulta até as tarefas simples. Eu sugiro que você procure alternativas e não se deixe levar pelo MSBuild. Especialmente, observe a maneira como o gulp e o sbt funcionam.

@shederman

Eu não gosto de XML. É um formato ruim para arquivos de projeto e configuração. Foi uma má ideia quando foi introduzido durante a fase "XML para tudo" e é uma má ideia agora.

Nada disso explica _porque_ é uma má ideia.

Acho que os arquivos JSON se fundem muito melhor do que os arquivos XML. Aceito que se trate de uma opinião, mas é minha e é baseada nas minhas experiências.

Eu tive nightmare .json mesclagens e nightmare .xml mesclagens, eu não estou particularmente interessado em qualquer uma delas quando se trata de mesclagem. Na minha experiência, as chances de uma mesclagem problemática aumentam com o _tamanho_ do arquivo, independentemente do formato.

Estou usando o vscode que não precisa e não usa arquivos xproj. Esse é meu cenário atual e não quero ou preciso de um arquivo xproj que não signifique nada para mim.

Isso não significa que você não possa olhar o arquivo xproj atual para ter uma ideia do que ele é. Ao não fazer isso, você está fazendo o equivalente de enfiar os dedos nos ouvidos, fechar os olhos e dizer "La la la".
Em outras palavras, você pode ficar chateado com o fato de que uma mudança está acontecendo e reclamar, sem conseguir nada, ou pode participar da conversa real e ajudar a direcionar o resultado disso.

Por exemplo, uma coisa que ainda está indecisa é se as dependências do nuget se tornarão parte do csproj ou se ele se tornará o nuget.json - sua preferência está aí. Depois de ter suas listas de dependências em um arquivo .json, o que resta no csproj? Com que frequência isso vai mudar? _Isso_ será difícil fazer a fusão?

Eu pessoalmente preferia que tudo estivesse contido em um único arquivo de projeto, mas posso ver o apelo e os benefícios de separar o nuget do próprio projeto. Há prós e contras em ambos e talvez a melhor solução seja permitir ambos, ter um csproj com uma lista de dependências, mas também permitir que você aponte para um arquivo .json com suas dependências. O melhor dos dois mundos e todos ganham, às custas de alguma complexidade adicional ao próprio MSbuild.

Não, estou discutindo o MSBuild. Já fiz muitas coisas com o MSBuild e o Team Build. Eles nunca foram divertidos e nunca foram fáceis e sempre envolveram lutar com o porco na lama. Eu odeio o MSBuild e certamente não estou sozinho.

Tendo que lidar com as definições de compilação baseadas em XAML do TFS, posso pelo menos concordar com você em (algumas) esta.

O MSBuild dificulta até as tarefas simples. Eu sugiro que você procure alternativas e não se deixe levar pelo MSBuild. Especialmente, observe a maneira como o gulp e o sbt funcionam.

Em seguida, sugiro que você pare de jogar seus brinquedos para fora do carrinho e participe ativamente da discussão sobre como a "nova" estrutura do projeto deve ser _realmente_. Imagine um futuro em que você tenha que lidar com um arquivo de projeto baseado em XML, como você gostaria que esse arquivo de projeto realmente se parecesse?

Imagine um futuro onde você terá que lidar com um arquivo de projeto baseado em XML

Hum. Ok, então devo imaginar um futuro que não quero e explicar para você como funcionaria? Hum, acho que não. Que tal olharmos para alguns sistemas de construção modernos e mais inovadores. você sabe, aqueles que deixaram o XML no passado distante.

E quanto a:

var gulp = require('gulp')
, minifyCss = require("gulp-minify-css");

gulp.task('minify-css', function () {
    gulp.src('./Css/one.css') // path to your file
    .pipe(minifyCss())
    .pipe(gulp.dest('path/to/destination'));
});

Ou talvez

organization := "com.devdaily"

name := "ScalatraTest1"

version := "0.1.0-SNAPSHOT"

scalaVersion := "2.9.1"

seq(webSettings :_*)

libraryDependencies ++= Seq(
  "org.scalatra" %% "scalatra" % "2.0.4",
  "org.scalatra" %% "scalatra-scalate" % "2.0.4",
  "org.scalatra" %% "scalatra-specs2" % "2.0.4" % "test",
  "ch.qos.logback" % "logback-classic" % "1.0.0" % "runtime",
  "org.eclipse.jetty" % "jetty-webapp" % "7.6.0.v20120127" % "container",
  "javax.servlet" % "servlet-api" % "2.5" % "provided",
  "com.mongodb.casbah" %% "casbah" % "2.1.5-1"
)

resolvers += "Sonatype OSS Snapshots" at "http://oss.sonatype.org/content/repositories/snapshots/"

Oh yeah, que xproj ligado a você é muito melhor. Agradável, claro e conciso. E expressivo, não se esqueça do expressivo. Para que serve esse ProjectGuid? E adoro os 90 caracteres para definir a versão da ferramenta. E o DnxInvisibleContent? Isso é útil para meu sistema de compilação saber? Quais arquivos não mostrar no IDE que não estou executando?

Eu sugiro que você pare de jogar seus brinquedos para fora do carrinho

Não quero :-)

Nah, terminei. Tive uma longa conversa com Immo e estou cansada de lutar esta batalha. Todo mundo tem sua visão parcial e ninguém quer ouvir o conceito ultrajante de que seu jeito pode não ser perfeito para todos.

[Editado para remover petulância]

@shederman : você mostra aqui os arquivos de definição de construção ; Eu quero me afastar das definições de construção como uma definição de projeto. Há espaço para definir os detalhes estáticos sobre um projeto / artefato a ser gerado, independentemente das instruções de como gerá-lo. O fato de isso unir os dois é um dos principais problemas no uso de arquivos MSBuild como arquivos de projeto.

Desejo ser capaz de especificar apenas as informações necessárias para descrever os artefatos a serem gerados e as dependências e o conjunto de ferramentas a serem usados, além do layout de vários elementos que compõem o projeto no disco. Todo o resto deve ser separado. Se você deseja usar o MSBuild sob o capô, vá em frente. O mesmo se você preferir gulp, babel ou sei lá o quê. Para mim, é isso que o project.json foi criado para fazer. (Eu não era fã da habilidade de definir comandos lá, no entanto)

Sim, isso faz sentido. Essa foi uma das coisas que gostei no project.json. Definiu o "o quê", não o "como". Ao colocar muitas coisas em um arquivo, tornamos o arquivo muito complexo, especialmente se nosso IDE for estúpido. E isso não é necessário para editores e IDEs simples.

A partir de uma IU com pouca cerimônia como o VS Code, não há muita necessidade de um sistema de projeto. É tudo construído. Muito disso é declarativo, dizendo o que deve ser construído e os metadados. Alguns podem ser imperativos, dizendo quais etapas devem ser executadas.

Sim, o maior problema do MSBuilds é que ele tenta fazer tudo em um sistema.

Acho que o que não estou entendendo é o seguinte: mostre-me alguns casos de uso que são aprimorados com o uso do MSBuild como o sistema do projeto, em vez de apenas fazer o project.json funcionar. Eu não vejo isso. Talvez meus casos de uso sejam muito simples, então me mostre alguns.

@shederman As notas standup mencionam a necessidade de poder compartilhar arquivos de origem entre projetos

Então ... este é um projeto de código aberto, e eu sei que a Microsoft é "o poder que existe", mas se isso é tão importante para as pessoas, então - e entendo que estou fazendo uma pergunta ignorante aqui - quanto tempo / esforço / energia precisaria ser gasto para permitir que o .NET Core continue usando o project.json como uma alternativa ao MSBuild? Se pessoas suficientes contribuem, e o código é bom o suficiente, então por que o MS não o aceitaria neste projeto? Parte da beleza (e queda) do Código Aberto é a ameaça de bifurcar o código se o (s) mantenedor (es) principal (is) recusar (m) muito do que é oferecido por outros. Parte do objetivo do código ser Open Source não é apenas olhar, mas modificar e melhorar.

Minha opinião pessoal sobre a mudança é que tem a ver com Xamarin, na medida em que se trata de planos futuros. Além disso, nas discussões recentes, acredito que os ouvi dizer que querem que a construção de aplicativos de console seja um cidadão de primeira classe. Lembre-se que originalmente o novo .NET (ASP.NET 5 + DNX) era focado na construção de aplicativos web, agora é mais. Tudo isso ocorreu há relativamente pouco tempo, as equipes .NET e ASP.NET se fundiram e também a compra do Xamarin. Eles chegaram à conclusão de que precisam de um sistema de projeto melhor para oferecer suporte a esses vários cenários (e novos cenários futuros sobre os quais não vou especular aqui) e também desejam lançar o .NET Core em breve. O que fazer? Ignorar completamente o MSBuild pré-existente que já pode lidar com o que é necessário e começar do zero? Desculpe, eu sei o caminho que escolheria.

Uma boa parte da preocupação parece ser em torno da fusão, MAS se o arquivo do projeto não contém os nomes dos arquivos no projeto, e se as dependências são colocadas em um arquivo de configuração separado, o problema de fusão deve desaparecer, pois os arquivos do projeto devem então mudar relativamente infrequentemente.

Apenas minha opinião

O problema de mesclagem é apenas um problema. Ficar longe do MSBuild é outra. Um resultado maluco desse cenário é que agora eles vão gastar tempo e esforço portando o MSBuild para Linux e OSX! Imagine isso.

Eu entendo seus motivos, mas seus motivos não funcionam para mim de forma alguma, e não funcionam para muitas pessoas. Fizemos investimentos com base em garantias firmes sobre a direção que estavam tomando, e eles voltaram com responsabilidade zero e nada mais do que uma indicação de que talvez devessem ter _comunicado_ melhor a decisão. Eles estão tomando uma decisão sobre project.json com base em casos extremos que o MSBuild oferece suporte e em como seria difícil dar suporte a esses casos extremos. Bem, isso significa que _nunca_ deixará de ser usado, porque ninguém em sã consciência daria suporte a todos esses casos extremos. Certamente ninguém fazendo projetos ASP.NET precisa desses casos extremos.

A bifurcação é uma possibilidade, mas considerando o quão grande e integrado tudo é, é uma perspectiva assustadora considerar até mesmo aprender o código relevante. A realidade é que este não é realmente um projeto de código aberto, é um projeto da Microsoft, e eles tomaram uma decisão corporativa sem nossa contribuição, e devemos apenas engolir e aceitar. Ficou claro para mim que basicamente não há possibilidade de que eles _nunca_ reconsiderem, não importa a oposição que haja.

Então, ou gastamos o esforço e bifurcamos o sistema de compilação project.json, ou mudamos para outro sistema de compilação (FAKE?), Ou você engole ou usa outra plataforma. Eu acredito que enumerei todas as escolhas lá.

@shederman MSBuild é open source desde o início de 2015, e as compilações estão passando no OSX / Ubuntu, então não acho que seja tão trabalhoso quanto você imagina para portar (https://github.com/Microsoft/msbuild) , navegando no repo, parece que a OSX estava construindo tudo bem em março, por exemplo.

Oh céus. Estou preocupado em saber se _devemos_ fazer isso, e eles saíram e fizeram ...

Sinta-se um pouco como alguém assistindo o Monstro de Frankensteins disparar para longe. Interessado, intrigado, preocupado e mais do que um pouco enojado :-)

@darrelmiller As notas de standup mencionam a necessidade de poder compartilhar arquivos de origem entre projetos

Sério? As pessoas ainda fazem isso? Quer dizer, eu costumava fazer isso para AssemblyInfo.cs e, na Idade das Trevas, colocávamos nossa chave de nome forte em um arquivo de código-fonte compartilhado.

Ok, esse é um caso de uso, mas agora eu realmente quero ouvir um caso de uso para o caso de uso. Intrigado.

@shederman

Hum. Ok, então devo imaginar um futuro que não quero e explicar para você como funcionaria? Hum, não acho que não

Tudo o que você precisa fazer é aceitar XML em vez de JSON, para ver quais podem ser os benefícios, mas você não está disposto a jogar esse jogo porque tudo o que deseja fazer é falar sobre o quão ruim é o XML, sem realmente declarar o porquê .

Oh céus. Estou preocupado se devemos fazer isso, e eles foram e fizeram ...

Eles têm estado "saindo e fazendo isso" literalmente _anos_ agora. Eles falaram sobre open-source .net anos atrás, deram roteiros e deixaram claro que se tratava de rodar em qualquer plataforma, eventualmente, para qualquer caso de uso.

Você está muito chateado com essa mudança e eu suspeito que a maioria das pessoas chateadas com a mudança são todos desenvolvedores da web, mas isso é apenas uma pequena parte do ecossistema .net, há um enorme ecossistema de serviços, desenvolvedores móveis e em nuvem que têm enormes bibliotecas de código que desejam portar para o núcleo .net. Goste ou não, project.json simplesmente não funciona atualmente para todos esses modelos. Você diz "faça funcionar", mas acabará com outro arquivo de projeto bagunçado, exceto um que não tem uma estrutura óbvia e claramente definida e - pior ainda - sem comentários. Esse último ponto é motivo suficiente para repensar o project.json.

Sim, aquele xproj ao qual você ligou é muito melhor. Agradável, claro e conciso. E expressivo, não se esqueça do expressivo.

Pelo menos você finalmente olhou para ele. Levou apenas 72 comentários nesta edição antes mesmo de você se incomodar? Eu continuo dizendo isso, mas você não está entendendo: em vez de reclamar sobre como o MSBuild é terrível, fale sobre por que ele é terrível .

O problema de mesclagem é apenas um problema. Ficar longe do MSBuild é outra.

Por que isso é mesmo um problema? Você odeia o MSBuild, nós entendemos isso, mas o que você odeia no MSBuild além do fato de que _darsa_ usar XML?

Um resultado maluco desse cenário é que agora eles vão gastar tempo e esforço portando o MSBuild para Linux e OSX! Imagine isso.

Você tem razão! Isso vai ser horrível, ser capaz de desenvolver qualquer tipo de aplicativo .net em qualquer plataforma que você quiser, usando qualquer IDE que você quiser. Pense nas crianças!
Como a Microsoft ousa gastar tempo abrindo o código-fonte de seu trabalho e portando suas ferramentas para outras plataformas em vez de investir em sua própria tecnologia de código-fonte fechado.

Eu entendo seus motivos, mas seus motivos não funcionam para mim de forma alguma, e não funcionam para muitas pessoas.

Mas talvez eles trabalhem para muito mais pessoas do que você?

Fizemos investimentos com base em garantias firmes sobre a direção que eles estavam tomando, e eles voltaram atrás com responsabilidade zero e nada mais do que uma indicação de que talvez devessem ter comunicado melhor a decisão.

A que _direção_ você está se referindo? O objetivo sempre foi .net em todos os lugares, "Qualquer desenvolvedor, qualquer aplicativo, qualquer plataforma" é o mantra do dia e não há absolutamente nada sobre essa mudança que afete isso. Eles declararam claramente que seus objetivos são manter o arquivo do projeto pequeno, simples, legível e editável por humanos sem um IDE. Nada está sendo tirado de você. Você pode ter que lidar com um pouco de XML, grande grito, se isso significa que .net é uma experiência de primeira classe para dispositivos móveis, nuvem e web, então vale a pena.

Eles estão tomando uma decisão sobre project.json com base em casos extremos que o MSBuild oferece suporte

Isso está muito além dos casos _edge_, é ridículo até mesmo sugerir que project.json é quase perfeito.

Certamente ninguém fazendo projetos ASP.NET precisa desses casos extremos.

Suponho que este seja o ponto crucial da questão: você não se importa com ninguém além de você, um desenvolvedor asp.net. É justo, mas, novamente, eu diria a você: aceite que outros desenvolvedores são importantes e, em vez de apenas jogar seus braços para cima, trabalhe para torná-lo o melhor sistema possível. Isso não significa criar uma sintaxe arbitrária para uma marcação completamente diferente, significa aceitar que a imagem é maior do que apenas você e trabalhar com outras pessoas para torná-la ótima para todos.
Como sempre digo, se nuget.json listou todas as suas dependências, o que resta? Qual é o problema em definir alguns campos razoavelmente estáticos em elementos nomeados de XML?

A realidade é que este não é realmente um projeto de código aberto

Como outros já disseram, ser open source não significa dobrar-se para trás para alguns reclamantes. Eles aceitam solicitações de pull, escrevam algo melhor.

considerando o quão grande e integrado tudo é, é uma perspectiva assustadora considerar até mesmo aprender o código relevante.

Ok, basicamente estou lendo isso como "Não entendo o quadro geral e não quero entender o quadro geral, no entanto, continuarei reclamando porque isso afeta minha pequena bolha com um completo desprezo pelas implicações minha bolha tem nos outros ".

Então, ou gastamos o esforço e bifurcamos o sistema de compilação project.json, ou mudamos para outro sistema de compilação (FAKE?), Ou você engole ou usa outra plataforma. Eu acredito que enumerei todas as escolhas lá.

Ou ... quero dizer, este é apenas um pensamento louco e fora da caixa, mas você pode tentar contribuir com algo construtivo para a conversa.

Voltando ao assunto ....

Pensei mais nisso e agora estou inclinado a fazer com que o project.json se torne nuget.json, mantendo o gerenciamento de dependências como está agora. Funciona bem agora, o intellisense já está lá e é consistente com coisas como gulp e npm.

Deixe o csproj simplesmente definir as partes estáticas.

No entanto, a desvantagem dessa abordagem que posso ver é que não tenho certeza de como isso funcionaria bem ao direcionar vários frameworks, realmente não acho que faça sentido colocar isso em nuget.json, mas nuget.json é ainda vai ter que saber sobre isso.

project.json não é apenas um arquivo json.
csproj não é apenas um arquivo XML.

IMHO muitas pessoas, como eu, ficaram entusiasmadas em ver a Microsoft, mais precisamente a equipe Asp.Net,
libertando-se de códigos / conceitos / sistemas / ferramentas / aparências / legados muito antigos ...

Isso nos deu 'esperança'!

Eu desenvolvo Asp.Net desde os primeiros bits de visualização. Gosto principalmente de trabalhar com isso. Mas depois de 15 anos,
as coisas 'antigas', como XML, parecem muito, muito pesadas e desatualizadas. A percepção é importante.

Sem XML e pelo menos usando JSON, minha 'felicidade de desenvolvedor' é muito maior.
Posso trabalhar com coisas, o resto do mundo decidiu usar. Meu IDE facilita essas coisas em relação aos formatos legados.
Eu não preciso mais pagar o 'Imposto Angle Bracket'.

Remover o project.json não é grande coisa, mas fazê-lo a portas fechadas quase no último momento mata essa 'esperança' instantaneamente.

De repente, isso não parece mais um projeto de código aberto.

Fyi: "Asp.Net Core" tem muitos recursos fantásticos. Eu principalmente amo isso.
A equipe do Asp.Net é ótima e eu não poderia estar mais orgulhoso de ser um desenvolvedor do Asp.Net.

Mas estou ferido. Talvez eu não seja o único.

Apenas meus 2 centavos.

Acho que podemos concordar que o msbuild (especialmente como o VS o usa) não é perfeito, e enquanto eu estava animado com o project.json, era mais sobre o MS consertar muitos dos meus pontos fracos e para ser honesto, contanto que eles fazem eu provavelmente não me importarei muito sobre como eles fizeram isso.

• As mesclagens de csproj não funcionam muito bem, estou precisando consertar manualmente uma mesclagem com defeito a cada duas semanas. Remover a lista de arquivos do csproj ajudaria muito aqui.
• As referências do NuGet e as referências do projeto nem sempre se alinham, mais uma vez, pode ser devido a mesclagens interrompidas. De qualquer forma, é incômodo diagnosticar e corrigir.
• Ocasionalmente, preciso me conectar ao processo de construção (não tenho certeza de como isso deveria funcionar em project.json), mas toda a necessidade de descarregar / carregar torna a depuração do script de construção um processo doloroso.

Se eles encontrarem uma maneira de consertar esses 3 itens, então eu provavelmente não reclamaria tanto sobre os arquivos csproj.

@neoKushan

tudo o que você quer fazer é falar sobre o quão ruim é o XML, sem realmente dizer por que

Não totalmente justo, também quero falar sobre como o MSBuild é ruim :-)

Tenho certeza de que realmente _disse_ por que não gosto de XML para arquivos de construção, mas deixe-me tentar novamente. XML é prolixo, é feio, é melhor para ferramentas do que para edição manual, e não gosto da experiência de mesclá-lo. Ele era usado para o MSBuild porque, naquela época, a indústria pensava que o XML poderia ser usado para tudo. Seguimos em frente desde então. Bem, em alguns lugares.

pior ainda - sem comentários

Acredito que várias pessoas ofereceram alternativas aqui. HJson é apenas uma opção. Yay! Não temos que repensar isso afinal ;-)

Você está muito chateado com essa mudança

Para ser justo, estou principalmente chateado com a forma como essa mudança foi feita em uma sala fechada, sem considerar ou se envolver com a comunidade que havia aceitado o apoio anterior muito firme para project.json pelo seu valor nominal. Rapaz, não vou cometer ESSE erro de novo!

Não me entenda mal, não gosto de XML, não gosto de MSBuild. Mas odeio ouvir que devo adotar algo que eu realmente amo e depois ouvir no último minuto que isso está sendo levado embora. Não mova meu queijo!

Eu suspeito que a maioria das pessoas chateadas com a mudança são todos desenvolvedores da web

Umm, sim, isso seria porque eles são os únicos desenvolvedores para os quais você ofereceu o project.json. Em outras notícias, os desenvolvedores do Swift também não estão chateados com a decisão. Quero dizer, pense no que você está dizendo aqui:

1. Apenas desenvolvedores da web têm esse novo recurso
2. Muitos deles ficaram realmente chateados quando o tiramos
3. Ninguém mais pode usar isso
4. As pessoas que não o usaram não ficaram chateadas por ele ter sido levado embora
   logo, todos os outros desenvolvedores não gostariam disso.

Acho que você precisa dar uma olhada na qualidade do seu pensamento, e foi isso que tentei questionar por algum tempo e não cheguei a lugar nenhum. A falta de informação sobre o pensamento, e o fato de que as partes relevantes se calaram, indica-me que o pensamento pode ter sido suspeito.

E o que você quer dizer com "desenvolvedores da web"? Você está pensando em algum pequeno site para uma pequena empresa? Que tal uma pilha de microsserviços, dando suporte a um negócio de gerenciamento de ativos com dezenas de bilhões de dólares sob gerenciamento. Claro, há um site lá também. Mas isso é cerca de 10% do sistema. Ah, e sim, ele também é direcionado à nuvem, então talvez estejamos realmente falando de "desenvolvedores de nuvem".

Parece que você nem mesmo entende como a tecnologia sobre a qual está tomando decisões precipitadas está sendo usada, ou por quem.

o que você odeia no MSBuild além do fato de que ele ousa usar XML

É muito complicado
É uma incompatibilidade de impedância, empurrando a lógica baseada em inferência para situações em que as pessoas estão lidando principalmente com lógica imperativa ou declarativa.
Meu Deus, cara, você realmente _ olhou_ os arquivos MSBuild? Ok, desculpe, você disse além de usar XML ;-)
A forma como as propriedades e itens são declarados é contra-intuitiva para quem não os usa regularmente
É usado como uma ferramenta de tamanho único que tenta realizar tarefas que deveriam ser feitas em scripts. Martelo, pregos.
Em um grande número de casos, tudo o que ele faz em um arquivo grande pode ser expresso em, no máximo, 3 linhas de script
O lixo do VS que é vomitado nele. Ouvi dizer que vai ser consertado. Esperando com alguma apreensão para ver se isso também é cortado. Como mencionei acima, agora estou um pouco tímido quanto a promessas.

O que você ama tanto? E o mais importante, você está disposto a aceitar que outras pessoas podem não compartilhar de seus pontos de vista? Em caso afirmativo, você pode admitir que "tamanho único" pode não ser a abordagem certa?

A que direção você está se referindo

project.json é a base de nossa nova abordagem de projeto é o que foi comunicado. Investimos dinheiro real, tempo e sofrimento com base nesse compromisso.

Mas talvez eles trabalhem para muito mais pessoas do que você?

Talvez sim. Mas se for assim, onde está a evidência disso? Tentei interrogar o pensamento e a tomada de decisão e as evidências usadas nisso e não recebo nada de ninguém. Por todas as evidências fornecidas, você poderia ter sacudido uma bola 8 mágica, pelo que sabemos.

Ninguém sabe quantos pensam de uma forma ou de outra. Na verdade, sou o único que conheço que realmente tentou descobrir.

Você não se preocupa com ninguém além de você mesmo, um desenvolvedor asp.net

Não é muito bom. O que estou realmente dizendo é que a afirmação é que a nova direção funciona para todos os casos de uso, e estou levantando minha mão e dizendo que não funciona para mim. Você é aquele que está cavalgando mal sobre toda a oposição. Sou eu que pergunto às pessoas o que elas pensam, a EM não é.

Em nenhum momento eu disse "livrar-se inteiramente do MSBuild e impor meu processo de compilação em todos os outros desenvolvedores". Você é quem

Podemos discutir o quão viável isso é, e talvez não seja, mas não sabemos , porque nunca fomos consultados ou comprometidos.

Você realmente ama seu argumento do meio excluído.

Eles aceitam solicitações pull

Sério? Se emitíssemos uma solicitação pull que deixasse uma ferramenta de compilação não baseada em MSBuild na funcionalidade de ferramenta principal, que lia apenas project.json, você a incluiria na estrutura? Sério?

Ok, basicamente estou lendo isso como ...

Uau, você leu muito sobre isso. Puxa, se eu ler como você, nunca terminaria um livro. E seria bem diferente do que o autor escreveu.

Em vez disso, tente: "Não entendo totalmente o quadro geral e estou considerando o esforço e o tempo que seria necessário para fazer isso. Seria muito melhor se tivéssemos a ajuda dos desenvolvedores existentes para fornecer uma fração significativa da comunidade deseja, mas acho que, se eles não se importarem com o que os usuários desejam, talvez tenhamos que seguir esse caminho. "

Droga! Eu leio como você! Exceto que na verdade se encaixa um pouco melhor no texto original do que suas interpretações um tanto histéricas.

você pode realmente tentar contribuir com algo construtivo para a conversa.

Bem, eu pensei que estava sendo construtivo, na verdade. Depois de superar o choque inicial, tentei descobrir qual era a base dessa decisão. Tentei descobrir como era o processo de tomada de decisão. Tentei interrogar a qualidade do pensamento que estava por trás disso. Quando me disseram que a maioria dos desenvolvedores queria isso, mas nenhuma evidência foi fornecida para apoiar essa afirmação, eu realmente perguntei a eles, qual _nenhum_ na equipe havia feito BTW.

O que eu ganhei? Obstrução, insultos e evasões. Então me diga, por que você considera não construtivo perguntar se alguém que está tomando uma decisão importante que afeta milhões de pessoas fez seu dever de casa? E você considera construtivo ou suspeito quando ditas pessoas se recusam a mostrar o livro de dever de casa?

Quero dizer, realisticamente, estes são os cenários prováveis:
1) Você tomou a decisão com base em um conjunto completo de feedback e informações, e a decisão é de longe a melhor opção para seguir em frente. Se for assim, eu calaria a boca, eu prometo. Acho essa situação bastante improvável devido ao nível de oposição que você recebeu e ao fato de estar escondendo as evidências e a tomada de decisão.
2) Você tomou a decisão com base em visualizações parciais, mas a melhor que você tinha na época. Eu diria que a resposta correta seria reabrir a decisão e solicitar as opiniões que você omitiu. Acho que esta é a situação mais provável.
3) Você tomou uma decisão errada ou com base em informações ruins. Nesse caso, novamente, você deve reabrir a decisão e solicitar a comunidade. Eu realmente não acho que essa seja a situação, porque, por mais que você não acredite em mim, eu respeito imensamente os desenvolvedores do DotNetCore. Todos eles.

E sabe de uma coisa, se você reabrir a decisão, solicitar os pontos de vista, e a decisão vier da mesma forma que veio, então qual é o problema? E se, depois de solicitar os pontos de vista, você perceber que parte de sua tomada de decisão foi falha e você corrigir isso, não é realmente melhor ?

Uau, sério. Podemos acabar com isso?

Pergunta simples: vocês vão levar a oposição a bordo e relembrar a decisão com base nas novas informações?

Ou vai continuar apenas insinuando que as pessoas que discordam de você são loucas, estúpidas, não qualificadas, _ininformadas_ ou, de outra forma, incapazes de sustentar uma opinião válida e informada?

Sugestão: Microsoft fork para oferecer suporte a clientes legados msbuild csproj. #carryOnAsNormal

Eu também sou um desenvolvedor .Net de longa data, estava trabalhando com visualizações de 1.0 antes mesmo de o marketing inventar o nome .Net. Sem se perder muito no mato, aqui estão meus dois centavos.

Eu poderia passar o resto da minha vida sem nunca ver outro arquivo de configuração xml e ser perfeitamente feliz.

Eu não quero configuração xml. Qualquer lugar. Sempre.

Eu não me importo se a equipe consertar todos os pontos de dor do csproj; se ainda for um arquivo de configuração xml quando terminar, então não estou interessado. Você pode muito bem manter o sistema de projetos .net 4.5.

Quanto ao MSBuild ... O MSBuild pode morrer em um incêndio.

Eu entendo que ele é poderoso e existe um monte de ferramentas em torno dele, mas fora do MS, apenas especialistas em MSBuild realmente sabem o que ele faz ou como funciona. Cada vez que preciso inserir alguma customização no processo de build, acabo perdendo de 3 a 5 dias de minha vida profissional. Raramente consigo fazer com que algo, mesmo coisas triviais, como apenas incluir uma pasta vazia na saída, funcione bem no VS, publicação do VS e meu servidor de CI, tudo ao mesmo tempo.

Entendi ... se você não tem tempo para construir um bom substituto para o MSBuild para o período de tempo do asp.net core 1.0, então com certeza ... encontre uma maneira de continuar aproveitando o MSBuild até o asp.net core 2.0 ciclo; mas pelo menos continue trabalhando no sentido de substituir aquele cocô por algo com que o resto de nós possamos ser capazes de trabalhar.

Enquanto isso, tente manter o máximo possível da configuração em json. Não me importo especificamente se é project.json ou algo novo e melhor. Se necessário, faça com que o conjunto de ferramentas gere arquivos MSBuild legados rapidamente quando / se necessário - cole-os em uma subpasta em algum lugar ou algo assim.

O que eu não quero é meu sistema de arquivos parecido com este:

• bower.json
• package.json
• nuget.json
• everything-else.json
• microsoft-old-ass.xml.csproj

Além disso, você pode corrigir o limite de comprimento do caminho de 260 caracteres ... por favor ... sim, eu sei que isso tem muito a ver com o Windows, mas sério ... é 2016..

PS. Se você estiver indo para continuar ignorando a oposição, você pode fornecer o seguinte:

• Como obteríamos acesso aos canais de desenvolvimento de ferramentas de construção
• Uma visão de alto nível da arquitetura e do código atuais e onde as mudanças para mover para MSBuild / xproj serão feitas para que possamos planejar nossa abordagem para manter os bits que queremos e integrar bem.
• Garantia de que as solicitações de pull de cozimento em ferramentas baseadas em project.json serão aceitas se atenderem aos critérios de qualidade
• Garantia de que, se os critérios de qualidade forem atendidos, podemos incluir suporte "dotnet build" para project.json completo, bem como modelos ASP.NET Simple e, potencialmente, alguns modelos para tipos de projeto mais padrão também.

"Seja construtivo", "não contribua, não ganhe voz". Bem, você consegue o que você pede ...

@ Mike-EEE, quer fazer serializações Xaml para SimpleUseCaseBuild?

Depois de ler tudo isso, cheguei a estas conclusões:

• project.json trouxe muitas melhorias. Nada disso teria sido possível se o núcleo .net e asp.net estivessem vinculados a ferramentas e códigos legados
• project.json (e json) não é perfeito
• xml vs json vs anyserializationlanguage são estéreis. As discussões sobre como aproveitá-los para responder aos principais desafios do .net seriam mais interessantes
• voltar ao msbuild é trazer de volta o legado e provavelmente significa que não veremos mais melhorias no sistema do projeto, porque as equipes .net provavelmente perderão um pouco de sua liberdade

Espero que as equipes .net respirem fundo, parem um pouco, coletem feedback (e considerem a adoção e percepção dessa nova pilha) e desafiem a abordagem msbuild (que pode não ser tão ruim quanto alguns de nós pensam) com algumas alternativas. Acho que é preciso nos apressar.

LOL @shederman, no que você me puxou agora ?! : smile: E QUE discussão! Realmente incrível.

xml vs json vs anyserializationlanguage são estéreis. As discussões sobre como aproveitá-los para responder aos principais desafios do .net seriam mais interessantes

Sim, para mim o que é importante é o modelo de apoio usado para descrever os projetos e / ou o que eles fazem, e parte desta conversa tocou nisso. Eu gostaria de ver um modelo de projeto / API aprimorado que seja mais fácil de descrever e trabalhar (não importa o formato em que esteja descrito - embora sim eu faça: coração: meu Xaml!). Tenho uma discussão aberta sobre o repo do MSBuild aqui (https://github.com/Microsoft/msbuild/issues/613) em relação a isso e também sobre o sistema de projeto de Roslyn (https://github.com/dotnet/roslyn-project -system / issues / 37) também, se estiver interessado.

Muitos pontos realmente excelentes aqui, e eu pessoalmente estou cavando a energia, "não construtiva" ou não. Acho que todos aqui estão empenhados em melhorar a MSFT e tirar o melhor proveito do que está sendo produzido. : +1:

Meus 2 centavos:

Acredito que haja dois tipos de pessoas discutindo essa mudança:

• desenvolvedores que têm usado VS & .NET para construir _varios_ tipos de projetos e precisam dar suporte a esses projetos por muito tempo
• desenvolvedores que não têm essa bagagem e desejam uma estrutura ASP.NET Core nova, limpa e sofisticada e de plataforma cruzada

Pessoalmente, estou na primeira categoria, então quero que o novo ASP.NET Core seja o mais compatível possível com outros tipos de projeto VS possível, e mudar para a "velha" solução csproj / msbuild é uma vitória para mim (+ meu equipe e provavelmente muitos outros desenvolvedores). Dessa forma, a transição seria muito mais suave e clara. Talvez as pessoas da segunda categoria não concordem comigo (ou simplesmente não se importam).

O único grande problema que vejo agora é como os pacotes NuGet são definidos e referenciados. É uma dor ter que manter os arquivos packages.config e csproj (como @JulianRooze já mencionado em https://github.com/aspnet/Home/issues/1433#issuecomment-218606377). Isso tem que ser refatorado. Idealmente, deve ser feito como @ cwe1ss sugerido em https://github.com/aspnet/Home/issues/1433#issuecomment-218519705). Foi um dos comentários mais construtivos neste tópico BTW ...

Quanto à guerra santa XML / JSON ... IMHO, XML é melhor para edição manual do que JSON. XML suporta comentários e tem mais informações de contexto quando você está olhando para ele. JSON é melhor para dados, não para arquivos de configuração. A mesclagem é igualmente boa e ruim para os dois formatos, depende exclusivamente do conteúdo. Se as referências do projeto fossem separadas dos arquivos csproj atuais, a fusão também se tornaria muito mais fácil ...

@Funbit tentar categorizar as pessoas não ajudará. E eu não me encaixo em nenhuma de suas categorias. Sou um desenvolvedor asp.net desde v1 betas. Quase parei de ser um 2 anos atrás, mas o .net core me trouxe de volta porque era o melhor do .net e do mundo do node.

Quero que o .net core seja um sucesso, não um velho techno corporativo sem adoção e sem comunidade.

De minha parte, não me importo muito com essa decisão, não me importo muito com XML, e para roubar uma citação: "Os colchetes são melhores do que os colchetes angulares", mas não me incomoda muito voltar a csproj / msbuild - sou flexível, posso lidar com isso.

Eu gostaria de ecoar alguns dos comentários de @shederman :

A realidade é que este não é realmente um projeto de código aberto, é um projeto da Microsoft, e eles tomaram uma decisão corporativa sem nossa contribuição, e devemos apenas engolir e aceitar. Ficou claro para mim que basicamente não há possibilidade de que eles reconsiderem, não importa a oposição que haja.

e

Para ser justo, estou principalmente chateado com a forma como essa mudança foi feita em uma sala fechada, sem considerar ou se envolver com a comunidade que havia aceitado o apoio anterior muito firme para project.json pelo seu valor nominal. Rapaz, não vou cometer ESSE erro de novo!

Isso _não_ me incomoda, a Microsoft fez um grande negócio de open source .NET e quer realmente envolver e trabalhar com a comunidade, obter seus comentários e ser um bom 'membro' (parceiro?) Da comunidade. Mas esse tipo de coisa realmente atrasa todo o esforço e dá ao ecossistema .NET toda aquela sensação "borgish" de que o /. a comunidade o rotulou por anos.

Para ser justo com a Microsoft, eles não são os únicos a fazer esse tipo de coisa com um projeto patrocinado por uma empresa; lembra da divisão na comunidade nodejs (que causou a bifurcação io.js)? Mas acho que quando é a Microsoft, é muito pior.

Isso explodiu fora de proporção do que foi inicialmente planejado.

Isso explodiu fora de proporção do que foi inicialmente planejado

@MaximRouiller você mesmo desenvolvedor, mano ??? :sorriso:

@ Mike-EEE sim. Eu esperava alguma discussão acalorada, mas já vi muitos ataques pessoais. : desapontado:

necessidade de ser capaz de compartilhar arquivos de origem entre projetos

@darrelmiller Isso parece assustador para mim, porque parece implicar que a listagem de arquivos no .csproj está voltando.

@lokitoth Provavelmente não há razão para que os arquivos vinculados também não possam usar globs curinga.

@MaximRouiller Eu também sou culpado de ficar acelerado, ser impulsivo demais e falar o que penso. Eu pensei que era ruim, mas @shederman sabe como derrubar! Haha. A propósito, eu ia dizer que @shederman representa meu animal de codificação interno, mas isso foi antes de eu saber que existia um @CodingGorilla. :rindo:

Acho que precisamos nos lembrar de que o que fazemos é realmente um trabalho @shederman ), me ajudou a ver que talvez eu não saiba _tudo_ (ou mesmo _qualquer_coisa_ às vezes, parece!) e manter a mente aberta sobre as coisas. Eu ainda falho. Mesmo quando vi a iniciativa project.json, fiz o possível para apontar a divisão que ela estava criando, mas pode ter sido um pouco abrasivo demais com o pessoal aqui no repo ao fazê-lo.

De qualquer forma, é sempre melhor respirar fundo, (tentar) ter um espírito humilde, e nos lembrar que estamos no mesmo time, mesmo que esse time tenha sido dividido em campos "web" e "nativos" agora. Pode ser uma merda por um tempo, mas o que estamos falando aqui é algo que nos servirá por muito tempo - uma década ou mais, até. Vamos nos concentrar na abordagem de longo prazo e, ao mesmo tempo, ter empatia pelos outros e de onde eles vêm.

OK ... pregação e rah-rah o suficiente para o dia. : stick_out_tongue: De volta ao nosso slugfest regularmente agendado!

Isso parece assustador para mim, porque parece implicar que a listagem de arquivos no .csproj está voltando.

Além disso, como um aparte, eu sou a única pessoa no planeta que aprecia esse recurso? : stick_out_tongue:

Isso parece assustador para mim, porque parece implicar que a listagem de arquivos no .csproj está voltando.

Além disso, como um aparte, acho que sou a única pessoa no planeta que aprecia esse recurso? : stick_out_tongue:

@ Mike-EEE Sim, acho que você é. :piscar:

O principal caso de uso para arquivos vinculados é para múltiplas plataformas. Esse é um recurso do project.json que eu realmente quero manter. Não acho que tenha visto nenhum comentário específico sobre esse recurso, mas seria bom se a equipe pudesse afirmar sua intenção de recriar isso no msbuild.

@shederman sabe como derrubar!
😆

Eu tento. Espero não ter insultado ninguém. Eu tentei muito só ir atrás de argumentos.

Fico particularmente irritado com insultos pessoais sarcásticos, então qualquer pessoa que discuta contra mim NÃO é a maneira de me calar. 😉 E havia alguns desses.

Estou curioso sobre os casos de uso para edição de arquivos csproj. Minha experiência é que eu só tive que editar arquivos csproj quando o nuget bagunçou algo ou um hintpath foi quebrado. Para adicionar novas etapas ao processo de compilação, sempre usei um arquivo build.proj de nível superior que foi executado pelo meu sistema de CI. Eu nunca uso os arquivos .sln na minha configuração de CI.

É o objetivo principal que as pessoas desejam editar arquivos csproj para adicionar etapas BeforeBuild e AfterBuild que desejam executar ao depurar no Visual Studio?

@ Mike-EEE Maybe; Lembro-me principalmente de ser uma dor real no traseiro ao lidar com projetos com um grande número de arquivos (por exemplo, Expression Blend, Visual Studio XAML Designer, etc.) a ponto de trocá-lo pela seleção curinga - o que o VS faz não sei como trabalhar corretamente, o que significa que toda vez que adiciono um arquivo, tenho que recarregar o projeto (ou encontro o erro "este arquivo já foi adicionado" na compilação)

O que você realmente gosta sobre este "recurso" (não compartilhar arquivos entre projetos, que é obviamente útil, mas sobre o VS só funcionar corretamente quando cada arquivo é listado individualmente)?

O que você realmente gosta sobre este "recurso" (não compartilhar arquivos entre projetos, que é obviamente útil, mas sobre o VS só funcionar corretamente quando cada arquivo é listado individualmente)?

Admito que este é um mau hábito, mas gosto de poder remover arquivos do meu projeto quando estou fazendo refatoração. Ou mesmo de uma perspectiva histórica. Se eu sei que estou trabalhando em algo que talvez queira mais tarde, mantenho-o no disco, mas removo-o do projeto. Concedido, isso polui o controle de repositório / origem (consulte: mau hábito), mas eu gosto desse tipo de controle. Porque agora, quando eu quero aquele arquivo, não tenho que ficar mexendo no histórico de um repo (como encontrar esse histórico de um arquivo excluído ??? muito trabalho!), Simplesmente "mostro todos os arquivos" e adicione-o novamente à minha solução. História instantânea. :sorriso:

Estou curioso sobre os casos de uso para edição de arquivos csproj

Para .csproj (cada um desses eu fiz, e para a maioria, várias vezes)

• Se você precisar fazer referência a tipos de UWP em um aplicativo de desktop
• Se você precisar consertar o VS quebrando coisas com NuGet (especialmente em relação à adição de arquivos a.targets e .proj / .props inclui)
• Se você precisar alterar o layout da saída gerada
• Se você estiver refatorando projetos e renomeando assemblies
• Se você está fazendo uma grande refatoração que impacta muitos arquivos
• Se você teve um conflito de mesclagem porque várias pessoas estão trabalhando no mesmo projeto e você não está usando curingas
• Se você precisa entender por que a compilação de repente não está funcionando (Editar: eu deveria ter especificado - isso é mais um "por que preciso que seja legível e 'independente'")
• Se você precisar depurar conflitos de versão do assembly devido a dependências irritantes
• Se você está tentando adicionar um arquivo "vinculado" (compartilhado)

Para project.json

• Criar o arquivo do zero manualmente (extremamente importante)
• Adicionar / remover pacotes NuGet
• Mudando a estrutura de destino
• Alterar a versão do pacote de saída

@shederman , percebo que você está frustrado, mas quando responde com

Sério? As pessoas ainda fazem isso? Quer dizer, eu costumava fazer isso para AssemblyInfo.cs, e na Idade das Trevas

Você está definindo um tom. É bom fazer uma conversa cara a cara, mas neste tipo de ambiente, tende a abrir a porta para toda uma gama de comentários baseados em emoção que tende a polarizar a conversa e torna difícil focar nos pontos importantes. Eu sei que é difícil manter a emoção fora dessas discussões (minha língua está cheia de marcas de mordidas ;-)), mas realmente temos que tentar para manter a discussão útil.

@ Mike-EEE Você não poderia realizar a mesma coisa (sem listar todos os arquivos) usando o atributo / padrão Exclude ? Para registro, geralmente faço a mesma coisa, é muito útil quando você apenas deseja eliminar algo rapidamente sem ter que fazer um ciclo de commit / rollback.

Para registro, na verdade gosto da proposta de @Mike-EEE escrita usando Roslyn e tendo o arquivo de projeto um AST serializado. Mas só se conseguirmos torná-lo igualmente fácil de trabalhar usando apenas o bloco de notas. (Sim, quero dizer notepad, notepad ++ ou qualquer outra coisa mais avançada: esse é o "teste de fumaça" para a usabilidade de um formato de arquivo editável por humanos)

@CodingGorilla Estou aberto a isso. Eu preferiria que as ferramentas me ajudassem com isso (defina o padrão para mim em vez de descobrir como fazê-lo - se eu sentir que estou trabalhando com o DOS novamente, TODOS PERDE !!). Eu deveria ser capaz de ter exatamente a mesma experiência que tenho agora.

Então, basicamente, olhando para um modelo "opt-out" em vez de "opt-in".

Para aqueles que desejam editar arquivos de projeto sem descarregar .... https://twitter.com/migueldeicaza/status/730978470734401536

Para aqueles que desejam editar arquivos de projeto sem descarregar ....

@darrelmiller o que estou vendo aqui ... sugerindo usar o Xamarin Studio em vez disso? Sim, esse descarregamento / carregamento de negócios / fluxo de trabalho / experiência é o PIOR! Ele existe desde 2003, heh.

Apoio a noção de que o eventual arquivo deve ser facilmente editável e legível com um editor de texto padrão (ou seja, bloco de notas), seja qual for o formato.

Também acho que ferramentas melhores removeriam muitos dos pontos fracos por trás do csproj atual. O VS não é o melhor exemplo e acho que a experiência que o VS oferece é o que muitas pessoas realmente odeiam no sistema de projetos MSBuild.

@ Mike-EEE A resposta ao comentário de Miguel foi de David Kean, que trabalha no novo sistema de projeto. A equipe sabe que o VS também precisa ser capaz de fazer isso.

@ Mike-EEE Acho que o que quero dizer é que posso lidar com o que quer que eles surjam. O sistema de projeto MSBuild é robusto o suficiente para fazer quase qualquer coisa (a menos que como @shederman diga, ele _não_ pode ser XML). Acho que algumas pessoas estão apenas observando o "deve ser do meu jeito ou é uma FALHA", e como outra pessoa disse (desculpe esqueci quem, este tópico é YUUUUUUGE!) "Eu tento manter a mente aberta ..." e apenas se adapte.

Além disso, você pode aprender algo novo, e isso é sempre uma coisa boa. : sorrindo:

@neoKushan eu costumava escrever scripts msbuild do zero, é de fato muito mais poderoso do que msbuild com sabor. Mas também não foi ótimo, e estou muito feliz de não estar mais fazendo isso. Acho que poderíamos descobrir algo muito melhor do que isso.

@CodingGorilla Na verdade, minha principal

Eu me ofereci para fazer o trabalho sozinho para manter o suporte a project.json funcionando lado a lado com o xproj. Quem mais se preocupa faz o trabalho, certo?

E este é de fato o ponto crucial. A equipe me permitirá fazer essa contribuição? E se não, por que não? Afinal, é OSS, não é?

Então, se você gosta do MSBuild e quer sua potência, use o xproj.

E se você gosta do conjunto de ferramentas que foi criado para o ASP.NET Core, continue usando-o.

Eles usam o mesmo compilador subjacente.

E nem deveria ser muito trabalho em qualquer caso. Tudo o que tenho a fazer é refatorar o código que eles estão descontinuando em outro comando.

Idealmente, eu gostaria de poder usar "dotnet build", olhar o diretório e decidir qual usar com base nos arquivos que estão lá. Mas um sinalizador de opção na construção ou até mesmo um novo comando estaria bem.

@sandorfr Concordo que escrever arquivos MSBuild completos que definam seu processo de compilação _entire_ é nada menos que uma dor colossal, mas se não me engano, não é disso que estamos falando aqui - estamos falando sobre _just_ o projeto estrutura.

Colocando de outra forma, o MSBuild é um sistema enorme e poderoso e com isso vem muita complexidade - mas apenas se você usá-lo. O VS por padrão jogou um monte de porcaria que você não precisava e olhando para o xproj, fica claro que o MSBuild também não precisava dele. Se a equipe donet se concentrar em minimizar o que é necessário no csproj, deve ser relativamente mínimo e limpo para a maioria das pessoas. Os únicos que devem sofrer o "inferno da fusão" serão aqueles que querem essa funcionalidade extra (que eu suspeito que sejam os responsáveis ​​por essa mudança, seja na cabeça deles).

Ainda não há nada que impeça você de usar o sistema de compilação de sua escolha, seja CAKE ou TFS Team Services ou qualquer outro.

Novamente, isso estipula que a equipe faça "certo".

O VS não é o melhor exemplo e acho que a experiência que o VS oferece é o que muitas pessoas realmente odeiam no sistema de projetos MSBuild.

@neoKushan É assim que me sinto em relação ao TFS Build e ao Xaml. O Xaml é ridiculamente incrível (e ainda AMARIA vê-lo usado como um possível formato para "scripts" do MSBuild), mas seu uso no TFS Build deu a ele um nome ruim.

Não acho produtivo usar esse problema do github como uma janela de bate-papo. Eu queria manter as notificações de e-mail para este tópico no caso de alguém do MS responder, mas a quantidade de e-mails tornou-se irritante.

O sistema de projeto MSBuild é robusto o suficiente para fazer praticamente qualquer coisa

Isso é parte do problema e o que torna tão difícil entender o que está acontecendo em um arquivo csproj ao lê-lo, o que o torna uma escolha ruim para um formato de arquivo de projeto (não deve ser confundido com um formato de arquivo de definição de construção)

(Editar: adicionado)

Ainda não há nada que impeça você de usar o sistema de compilação de sua escolha, seja CAKE ou TFS Team Services ou qualquer outro.

Infelizmente, isso significa que estamos presos tentando encaixar nosso sistema de construção no MSBuild se quisermos que o VS seja capaz de se comunicar com ele (e funcionar corretamente quando há código gerenciado e nativo e queremos depurar). É por isso que, na verdade, acredito ser um _recurso_ separar o arquivo de projeto do arquivo de compilação.

Haha yeah @ cwe1ss (falando sobre melhorias nas ferramentas!) Eu estava pensando que o GitHub é terrível para quando as coisas

Posso sugerir que todos nós participemos da próxima luta da comunidade na quarta-feira? Suspeito que falarei principalmente sobre o lançamento do RC2 um ou dois dias antes (pode-se esperar!), Mas nos dará a todos a chance de enviar as perguntas necessárias e ter uma boa discussão franca com um público ao vivo que pode realmente dar respostas.

Posso sugerir que todos nós participemos da próxima luta da comunidade na quarta-feira?

Somente se @shederman representar. Quero vê-lo destruir desenvolvedores e suas ideias em tempo real. Como um evento WWE PPV!

Acho que a vantagem de project.json sobre [projectName] .csproj não é sobre o formato. É sobre não precisar ser compatível com todas as coisas antigas. Isso permitiu que fosse bem simples. Supondo que Damian Edward e a equipe possam cumprir todos os seus objetivos especificados, eu realmente não me importo com XML versus JSON versus YML versus ... O que é importante para mim é a simplicidade e não ter que ver as coisas que estão lá para o Windows quando estou no Linux .

@glennsills Não acho que haja realmente muito em um arquivo de projeto MSBuild que seja específico para _windows_, é mais que é específico para o próprio MS Build, ou outros tipos de projeto com os quais você simplesmente não se importa. Realmente não há necessidade de ter um monte de elementos vazios apenas para manter o MSBuild feliz. Espero que a equipe esteja planejando cortar o máximo possível, mas veremos.

@ Mike-EEE Somente se @shederman representar. Quero vê-lo destruir desenvolvedores e suas ideias em tempo real. Como um evento WWE PPV!

Vou tentar fazer isso. Eu te aviso que eu falo mais devagar do que digito, então não tenha muitas esperanças 😄

Então, correndo o risco de abrir uma lata de worms, dado https://github.com/dotnet/roslyn-project-system/issues/40 como as pessoas se sentiriam sobre um arquivo csproj genuinamente reduzido que continha apenas (por padrão ) o essencial para o projeto?

(Não transforme isso em um discurso do tipo "Eu odeio XML!").

Que tal um "Odeio discurso do MSBuild"?

@shederman

E se fizéssemos o MSBuild aceitar arquivos JSON? : rindo: (não pude resistir)

@shederman , é difícil levar qualquer tipo de discurso a sério e eu preferia que a Microsoft levasse essa _discussão_ a sério.

Da maneira que isso está acontecendo em 5 anos você estará programando Swift, Java (!!), Node.JS ou Elixir. ;)

Existem duas tecnologias ruins hoje em dia em projetos .NET / Soluções / o que quer que seja. Arquivos Nuget e .csproj. Se você trabalha em uma equipe de 5+ usando Git (e por exemplo, GitFlow) é um pesadelo total. O "que merda se esqueci de incluir o arquivo no .csproj" está ficando cansativo. O ferramental deve consertar isso, o ferramental também deve me avisar que tenho versões de DLL conflitantes, o ferramental deve me ajudar com a fusão.

Chega de besteira. Project.json parecia bom no início, mas então a política e os sentimentos aconteceram.

MS Team deve chamá-lo de beta, não RC.
Parece que não posso confiar nem mesmo quando o RTM será lançado, caso seja possível que a equipe MS decida enviar o RTM2 que quebrou tudo novamente.
Não sou pessimista, mas esse movimento em torno do .NET Core é muito estranho.

@neoKushan Vou tentar ser civilizado e não fazer um discurso inflamado. Dito isso, não acredito que nenhuma opção MSBuild seja boa e também não acredito que XML seja uma boa opção.

Não estou concordando com os termos da discussão em que tenho que desistir das posições que mantenho para entrar na discussão. Continuo ouvindo como aqueles de nós que defendem o project.json devem aceitar basicamente exatamente o que a MS decidiu, talvez com uma ou duas modificações menores.

Não vejo como isso se segue. Eu simplesmente quero o sistema de construção que foi prometido e comprometido. Se a MS não estiver disposta a mantê-la e continuá-la, eu me ofereci para.

Então, onde está o problema? Não estou pedindo à MS que desista de seus planos, não estou pedindo que acrescentem trabalho. Só estou pedindo a eles que me permitam cumprir as promessas que renegaram unilateralmente.

Quase um pedido revolucionário.

Meus 2 centavos:

Acredito que haja dois tipos de pessoas discutindo essa mudança:

desenvolvedores que têm usado VS & .NET para construir vários tipos de projetos e têm que oferecer suporte a esses projetos por muito tempo
desenvolvedores que não têm essa bagagem e desejam uma estrutura ASP.NET Core nova, limpa e sofisticada e de plataforma cruzada
Pessoalmente, estou na primeira categoria, então quero que o novo ASP.NET Core seja o mais compatível possível com outros tipos de projeto VS possível, e mudar para a "velha" solução csproj / msbuild é uma vitória para mim (+ meu equipe e provavelmente muitos outros desenvolvedores). Dessa forma, a transição seria muito mais suave e clara. Talvez as pessoas da segunda categoria não concordem comigo (ou simplesmente não se importam).

O único grande problema que vejo agora é como os pacotes NuGet são definidos e referenciados. É uma dor ter que manter os arquivos packages.config e csproj (como @JulianRooze já mencionado em # 1433 (comentário)). Isso tem que ser refatorado. Idealmente, deve ser feito como @ cwe1ss sugerido em # 1433 (comentário)). Foi um dos comentários mais construtivos neste tópico BTW ...

Quanto à guerra santa XML / JSON ... IMHO, XML é melhor para edição manual do que JSON. XML suporta comentários e tem mais informações de contexto quando você está olhando para ele. JSON é melhor para dados, não para arquivos de configuração. A mesclagem é igualmente boa e ruim para os dois formatos, depende exclusivamente do conteúdo. Se as referências do projeto fossem separadas dos arquivos csproj atuais, a fusão também se tornaria muito mais fácil ...

Eu também me encaixo na categoria um (desenvolvedores que têm desenvolvido vários projetos / tipos e precisam apoiá-los há muito tempo). Meu empregador tem milhões de linhas de código de projetos no formato csproj e também temos produtos mais novos em execução no ASP.NET RC1 e ramificação de desenvolvimento RC2. Aviso justo, também fazemos uso avançado do MSBuild com assemblies de tarefa MSBuild personalizados, etc.

A integração do mundo real entre os dois foi um fracasso (por vários motivos), especialmente considerando coisas como gerar wraps, regenerar wraps quando dependências embaladas mudam, como isso se parece no controle de origem (internamente suportamos e usamos Git e TFVC ), como os projetos fazem referência uns aos outros em uma solução no tempo de design no VS versus como eles são puxados no tempo de construção / implantação. O sistema nunca pareceu _certo_. Não fazia sentido que eu pudesse ter dois projetos separados, cada um com apenas arquivos .cs, mas esses dois tipos de projeto não podiam se misturar bem.

Nesse sentido, eu entendo perfeitamente por que é importante oferecer suporte a aplicativos e códigos que foram escritos até este ponto. Não acho que seja o momento certo para introduzir esse tipo de mudança, com todas as outras mudanças em andamento - parece que muita coisa está acontecendo ao mesmo tempo.

Talvez uma possível solução futura seja seguir a sugestão de outras pessoas e pensar em lançamentos LTS ou algo semelhante? Esta é uma conversa muito mais ampla, mas então algum recurso como a substituição do sistema de projeto poderia ser introduzido e dar às pessoas tempo para absorvê-lo.

Outra solução possível é um sistema de compilação mais plugável, mas essa é uma solução de longo prazo e não ajuda a conversa atual. Basicamente, permite / ou / terceiros.

Sobre as dependências do projeto, já temos toneladas de arquivos packages.config flutuando, portá-los para packages.json / nuget.json não é grande coisa. Tenho mais problemas com redirecionamentos de associação de assembly inconsistentes do que com o formato de armazenamento para dependências.

@shederman Você deixou bem conhecida sua opinião sobre o MSBuild, mas o que não deixou claro é sua _contenção_ real com o MSBuild. Isso é o que estou achando tão frustrante. Só quero saber os problemas reais que você encontrou com o MSBuild porque realmente sinto que eles podem ser resolvidos.

Ok, então você não gosta de XML, certo - o debate entre JSON e XML não é nada novo e nunca vamos resolver isso aqui. No entanto, esse não pode ser o _ único_ motivo pelo qual você odeia tanto o MSBuild. Quais são os problemas reais que você encontrou?

A razão pela qual pergunto - e continuo perguntando é que esses são os problemas exatos que a Microsoft deseja corrigir e, a menos que deixemos claro quais são os problemas, eles não serão corrigidos. Sabemos que muitas das coisas que odiamos no MSBuild já estão sendo consertadas:

1. Listagem de todos os arquivos do projeto - sendo removidos / corrigidos (na verdade, um problema do VS)
2. Inferno de mesclagem - corrigido por 1. na maioria dos casos
3. Complexidade / verbosidade desnecessária - esperançosamente resolvida por https://github.com/dotnet/roslyn-project-system/issues/40
4. Não é facilmente editável à mão - Novamente, corrigido por 1. e 3.

O que sobrou? Na verdade, vamos discutir os problemas com o MSBuild e ver se há uma solução que não envolva a bifurcação de tudo ou o abandono de dezenas de milhares de projetos intrincados e essenciais aos negócios. Essa é a discussão que eu _quero_ ter.

Meus 2 centavos sobre isso:
Por que diabos esse tipo de mudança ocorre agora? De acordo com o roteiro, falta apenas 1 mês para o lançamento final.
Quando eu olhei para isso pela primeira vez, pensei que fosse uma piada. Mas, infelizmente, não é.
Este é um grande tapa na cara da comunidade. Tal decisão deve ter longos tópicos de conversa ANTES de ser adotada, não depois.

@laskoviymishka (e alguns outros) como foi notado por @neoKushan aqui, esta mudança _não_ está acontecendo agora, esta será uma mudança pós RTM (mesmo RTM estará em fases). Portanto, toda a conversa sobre "por que a mudança de última hora" é um argumento um tanto falacioso, há tempo de ver como as coisas vão evoluir.

@laskoviymishka A mudança não está acontecendo antes do RTM.

RTM ainda usará project.json como é usado hoje (acredito que o esquema está mudando para RC2, mas isso estava acontecendo independentemente). A mudança para um "novo" csproj está programada para acontecer após o RTM e será feita gradualmente. Nada muda no RTM (exceto xproj é renomeado).

@CodingGorilla, este é o RC2, que será transferido para a versão 1.0 em um mês. No mundo real, isso significa que você para de desenvolver tudo e se concentra na estabilização. Essa mudança não é realmente estabilizar nada.

@neoKushan se isso vai acontecer após RTM, por que não asc comunidade sobre isso? Inicie um tópico de discussão no github. Comece a apontar argumentos etc. Por que deve ser forçado sem nenhuma conversa com os desenvolvedores?

IMHO, este movimento de project.json para project.csproj deve ser discutido antes de ser adotado. No momento não é uma boa decisão, pelo menos para mim.

@laskoviymishka Notas da comunidade : (ênfase adicionada)

No RC2 / Preview 1, não haverá alterações . Em RTM / Preview 2, _a única alteração, você verá se os arquivos xproj serão renomeados pelo Visual Studio para csproj_. Desse ponto em diante, project.json viverá ao lado de csproj. A equipe começará a migrar recursos de project.json para o arquivo csproj. É possível que o arquivo project.json permaneça e contenha todas as referências do pacote para NuGet e seja renomeado para nuget.json. A equipe já testou alguns trabalhos que mostram que você não precisará listar todos os arquivos em seu arquivo de projeto, um dos principais benefícios do modelo project.json.

Portanto, esta é principalmente uma mudança de ferramenta e, em um prazo muito curto (ou seja, RTM +), o arquivo project.json ainda estará lá e ainda funcionará da mesma forma que agora. A boa notícia sobre isso, eu acho, é que ainda há tempo para a comunidade ter um impacto sobre isso, se pudermos manter as coisas civis e construtivas.

@laskoviymishka Bem, eu realmente não quero falar pela Microsoft, não sei qual é o plano final deles, mas acho que eles também não sabem. Muitas pessoas estão dizendo que o tapete foi puxado debaixo deles e a Microsoft deveria ter nos consultado antes de decidir isso, mas realisticamente nada mudou ainda e nada vai mudar por meses - além disso, quando a mudança acontecer, será uma mudança gradual e, com sorte, que as ferramentas mais ou menos façam por você.

A Microsoft, ou pelo menos a equipe do asp.net, pediu comentários sobre isso e sem dúvida eles estão lendo esses tópicos, mas talvez o que esteja faltando seja um boletim ou postagem definitiva da Microsoft dizendo "Se você quiser discutir isso, faça _aqui_ ". No entanto, acho que a transição ocorre muito mais cedo do que as pessoas pensam. Até agora, a única coisa que eles sabem com certeza é renomear xproj para csproj.

Pessoalmente, sinto que, embora seja uma mudança um pouco chata, eu entendo suas razões para fazê-lo. Não tenho uma resposta melhor, então minha opinião é que se temos que lidar com projetos no estilo csproj, então podemos aproveitar este período para apresentar o melhor _tipo_ de csproj que pudermos. Não será project.json, mas se pudermos obter o melhor dos dois mundos, então, no longo prazo, estaremos todos melhor. Nem todo mundo concorda e está tudo bem.

@neoKushan, este é um bom ponto, espero que a MS veja. Será muito bom ver o feedback da equipe principal.

@CodingGorilla bem ainda há mudança na versão final, que está quebrando. O principal problema dessa mudança é que a equipe central tem que gastar muito tempo para nada. Esse é provavelmente o problema dos gerentes. Vamos gastar muitas horas de desenvolvimento apenas para mudar uma coisa que está funcionando para outra que provavelmente está funcionando. Sem nenhum bom motivo.

@neoKushan

Vamos discutir os problemas com o MSBuild

Estou tendo dificuldade em encontrar informações suficientes para formar uma opinião. Houve uma série de mudanças que _parecem_ ser ativadas por project.json e a eliminação de arquivos .csproj. Não quero que essas melhorias desapareçam, mas não sei como mudar para um msbuild "novo e melhorado" mudará meu fluxo de trabalho:

• Atualmente, usamos gulp para cada tarefa de construção. Isso muda? Meu gulpfile apenas executa para dnu ou dotnet-cli para realmente transformar uma coleção de arquivos .cs em um assembly. Eu posso ficar com isso, certo?
• O VS continuará a oferecer suporte ao explorador de tarefas e aos gatilhos afterbuild / prebuild / etc para minhas tarefas de gulp, para que os usuários do VS possam executar o F5? Ou eu tenho que fazer o msbuild lançar o gulp, o que significa que todas as minhas tarefas gulp precisam de tarefas msbuild do wrapper definidas? (ai)
• O msbuild está em uma instalação separada? Ele terá controle de versão separadamente do dotnet cli ou do tempo de execução? Como isso altera o mínimo que precisa estar disponível em meu servidor de compilação de CI? Mínimo para instalar em um ambiente de desenvolvimento?
• Se eu estiver usando um editor de texto para adicionar dependências nuget ou arquivos .cs, quais etapas extras devo adicionar, se houver?
• Quando estou revisando um conjunto de alterações em que um usuário do VS adicionou uma dependência nuget e um arquivo .cs, as alterações do csproj serão simples e legíveis por humanos? (Para comparação, com .net 4.6 e VS2015, minha opinião é que as alterações no csproj _não_ são facilmente legíveis por humanos.)

Eu gostaria de ver as pessoas que estão fazendo essa mudança buscar os cenários que eles precisam considerar (como o meu!), E discutir sobre isso acontecer. Espero que o tipo de coisa "ei, estamos mudando seu queijo sem qualquer discussão" não se torne o SOP do núcleo .net.

que o ferramental fará mais ou menos por você

E esse é o ponto crucial. Quanto menos ferramentas _requeridas_, melhor. Atualmente, posso usar um editor de texto e a linha de comando sem sentir que estou nadando contra a corrente. Espero que isso não mude. No terreno .net46, tenho que editar um arquivo xml gigante e prolixo se não quiser usar o VS, e misturar usuários do VS com usuários não-VS no mesmo projeto é um pesadelo.

"Bem-vindo ao RTM. Este é um lembrete de que o arquivo do seu projeto será alterado em um futuro muito próximo. Já decidimos isso. Razões, mas principalmente porque gostamos mais de ângulos do que de curvas e de ferramentas de construção, sim, construa Não determinamos o esquema final (mas será baseado em xml, veja acima), e o nome do arquivo definitivamente terminará com .csproj para lançar o máximo de confusão em qualquer ferramenta legada. Agile. (ps se você for um fornecedor de ferramentas:: o) "

@Oceanswave lindo exemplo de como você não deve gerenciar o desenvolvimento de software

@neoKushan

mas o que você não deixou claro é o seu problema real com o MSBuild

Talvez você devesse ler minha resposta anterior a esta mesma pergunta de você? https://github.com/aspnet/Home/issues/1433#issuecomment -218993559

Perdi centenas de horas ao longo dos anos consertando, desenvolvendo e depurando arquivos MSBuild. Já fiz Team Builds, criei enormes pipelines de construção e implantação. Passei horas e horas examinando registros detalhados tentando descobrir por que diabos alguma situação estranha está ocorrendo. Paguei minhas dívidas ao longo dos anos por esta tecnologia e, pessoalmente, não quero ter nada a ver com isso. project.json foi uma lufada de ar fresco. Depois de anos sofrendo com o MSBuild, finalmente tivemos a impressão de que o MS entendeu, que uma mudança era necessária e estava sendo aplicada.

E foi glorioso. Construções simples, edições simples, resultados rápidos e fáceis de entender. Ele lavou a memória daquelas horas xingando os scripts do MSBuild. Parecia que finalmente estávamos nos separando do cadáver do passado. Mas não, agora estamos algemados de volta ao cadáver que tanto odiamos, apesar da promessa de que isso não aconteceria.

Sem discussão, sem revisão, sem qualquer tipo de engajamento.

O fato de você nem mesmo estar ciente do quanto o MSBuild é odiado em alguns setores simplesmente prova que você não fez nenhuma diligência nessa decisão.

Não acredito que o MSBuild tenha limitações funcionais significativas como um sistema de compilação. É incrivelmente poderoso e, de certa forma, essa é sua principal fraqueza. É complicado porque precisa lidar com muitos cenários. Para um cenário simples de "restaurar, construir, testar, compactar", é realmente um grande exagero.

Em minhas equipes, estamos lidando com desenvolvedores C #. Eles estão sob pressão, prazos apertados, alto estresse. Eles não querem nada que os atrapalhe ou os atrase.

MSBuild é uma maneira diferente de pensar, uma grande mudança de contexto da codificação imperativa. Os desenvolvedores simplesmente odeiam. Eles acham isso obtuso e contra-intuitivo. Eles o evitam. O único MSBuild criado em qualquer uma das equipes que supervisiono atualmente é a ferramenta criada.

Não conheci um único desenvolvedor C # nos últimos 5 anos ou mais que estivesse animado ou gostasse de trabalhar com o MSBuild. Veja alguns dos comentários dos últimos dias no Github. Não estou de forma alguma sozinho em minha antipatia pelo MSBuild. O MSBuild foi percebido como uma pedra de moinho em torno do pescoço do desenvolvedor .NET por uma década. Grande parte dessa percepção é injusta? Sim, muito provavelmente.

Mas e daí? Da minha perspectiva como chefe de engenharia de software, preciso de ferramentas que produzam os resultados que desejo. Não consigo esses resultados com o MSBuild. Consigo esses resultados em project.json + gulp.js + powershell.

_Pode_ MSBuild me fornecer esses resultados? Claro que pode, mas apenas se os desenvolvedores trabalharem no MSBuild para obter esses resultados. E eles simplesmente não querem. Quando os forçamos , eles o fazem e depois não o mantêm.

Não posso confiar em uma ferramenta que os desenvolvedores odeiam. Essa é a realidade simples. E considerando o quanto adoro não usá-lo, não posso culpá-los.

Na verdade, vamos discutir os problemas com o MSBuild e ver se há uma solução que não envolva a bifurcação de tudo ou o abandono de dezenas de milhares de projetos intrincados e essenciais aos negócios.

Ok, então, o que pode ser feito?

Há cerca de 5 anos, se algumas das mudanças que estão sendo discutidas agora tivessem sido introduzidas, acho que a percepção seria melhor. Mas eles não eram e agora isso tem uma grande participação negativa entre um grande número de desenvolvedores. Pelo que me lembro, alguns desses mesmos problemas foram levantados com o MSBuild naquela época e rejeitados. Assim como as questões atuais estão sendo levantadas e rejeitadas.

Não sei como pode recuperar isso, realmente não sei. Eu acho que teria que haver algumas grandes rupturas limpas. Como você os faz sem quebrar o que está aí? É muito tarde, muito pouco. Portanto, não vejo um caminho a seguir com o MSBuild, não para mim, não para os desenvolvedores que trabalham para mim, não com meus parceiros, ou as equipes que trabalham para _teles_, não nos clientes que consultamos. Nenhum desses públicos deseja usar o MSBuild, eles o usam nas ferramentas porque precisam e juram repetidamente sobre isso. É certo que normalmente em torno da hora de mesclagem.

Então _agora_ você deseja tornar as mesclagens melhores? 10 anos depois. Depois que a ferramenta é um palavrão em muitos bairros?

Fundamentalmente, você está usando uma ferramenta projetada para Build Masters no final dos anos 90 que está realmente sendo usada por desenvolvedores que estão desenvolvendo seus esforços após 2010. Uma ferramenta que usa inferência para sua lógica sendo usada por desenvolvedores usados ​​para trabalhos imperativos e ferramentas imperativas. Uma ferramenta que usa uma maneira muito flexível, mas não óbvia, de definir propriedades sendo usadas por desenvolvedores que pensam que um conjunto de propriedades é um operador de atribuição simples e não entendem por que você iria querer fazer um PropertyGroup e não não me importo em descobrir.

Essa é a discussão que eu quero ter.

Claro, eu entendo. A discussão que eu quero ter é diferente, porém, é "dê-nos o que você nos prometeu, ou deixe-nos dar a nós mesmos, porque não gostamos da sua velha e nova ideia, e fazemos conforme o que foi prometido".

Posso compartilhar algo triste? De meus parceiros de negócios, que têm experiências semelhantes à minha (mais na verdade), eu era o mais pró-MSBuild naquela época. Na verdade, eu _usei_. Eu aprendi. Construí grandes pipelines. Mas isso foi há mais de 5 anos e muita água passou por baixo da ponte desde então.

Cara, eu me pego balançando a cabeça profusamente enquanto leio os comentários e a história de @shederman , pois é muito parecido com o meu. Eu gastei muito tempo no MSBuild e em seu DSL e realmente fui um pouco algumas vezes (sem mencionar a quantidade de tempo gasto por ter que aprendê-lo). Sua sintaxe e abordagem são diferentes de tudo em .NET e isso é parte do problema (é por isso que digo reiniciar / refazer / melhorar seu modelo de objeto e tentar novamente). Essa seria minha principal preocupação: é tão legado que a maneira como aborda os problemas é diferente de qualquer outra coisa (.NET) com que os desenvolvedores precisam trabalhar, e isso afasta o produto, em vez de promover o interesse / adoção.

Pense: Extensões do Visual Studio (.vsix). Ninguém quer tocá-los por causa de como são legados / antigos / diferentes em comparação com tudo o mais que existe hoje em dia. Bem, você tem ALGUNS desenvolvedores que querem, porque eles pagaram suas dívidas aprendendo seu sistema misterioso - assim como o MSBuild.

Eu também sou provavelmente o mais experiente entre todos que conheço profissionalmente que já lidou com o MSBuild. A maioria dos desenvolvedores não quer perder muito tempo aprendendo (porque você definitivamente faz isso). É quase como se fosse sua própria linguagem.

Se fosse "mais semelhante ao .NET" (e tivesse melhor integração com o VS), então acho que todos concordaríamos que seria um produto melhor para trabalhar e uma proposta atraente a se considerar.

@ Mike-EEE & @shederman Para o ponto de Mike, é antigo, arcaico e "diferente de tudo (.NET) os desenvolvedores precisam trabalhar com ...". Mas está além do reparo? Eles admitiram que há problemas que desejam consertar, então a questão é: pode ser consertado? Acho que conheço a resposta de @shederman , até concordo em grande parte com seu raciocínio (concordo com o tema de que construir e projetar sistemas é uma estranha mistura de preocupações).

Novamente, não tenho um cavalo nesta corrida, não me importo com o caminho que eles escolherem seguir. Eu realmente gosto de receber reações positivas e de me ouvir falar (com um lado de real interesse intelectual na conversa: rir:)

Eu realmente gosto de receber reações positivas e de me ouvir falar (com um lado de real interesse intelectual na conversa: rir:)

Feliz por ajudar! :sorriso:

Mas está além do reparo? Isso pode ser consertado?

Depende de quem você pergunta, realmente. Trazer questões ao repo como @shederman sugere tem sido difícil e desafiador (e sim, censurei minhas palavras lá: stick_out_tongue:). Parece que eles estão determinados em seus caminhos. Mas, como você sabe sobre a natureza do software, tudo é possível com tempo e esforço suficientes. :piscar:

@PhilipRieck Você está perguntando coisas realmente boas! Infelizmente não tenho respostas definitivas para todos eles, mas vamos ver:

Atualmente, usamos gulp para cada tarefa de construção. Isso muda? Meu gulpfile apenas executa para dnu ou dotnet-cli para realmente transformar uma coleção de arquivos .cs em um assembly. Eu posso ficar com isso, certo?

Não _ acho_ que isso vai mudar, estou 95% confiante de que o que estamos falando aqui afeta apenas a _definição_ do projeto, não como o projeto é realmente construído (pelo menos além de chamar dotnet build). O dotnet CLI pode chamar o MSbuild em algum ponto, mas nesse ponto é um tipo de coisa subjacente.

O msbuild está em uma instalação separada? Ele terá controle de versão separadamente do dotnet cli ou do tempo de execução? Como isso altera o mínimo que precisa estar disponível em meu servidor de compilação de CI? Mínimo para instalar em um ambiente de desenvolvimento?

Não tenho nenhuma resposta definitiva para isso, mas eu _imagino_ que o MSBuild vem como parte do dotnet CLI como uma instalação completamente separada, mesmo se você já tiver o MSBuild instalado (digamos com VS). Pura especulação da minha parte, no entanto. Eu sei que um grande objetivo de todo esse projeto ".net em todos os lugares" é ter o mínimo de barulho para fazer as pessoas se desenvolverem. Deve ser literalmente apt-get dotnet-cli (ou qualquer outro), dotnet new, dotnet build. Você nunca deveria ter que chamar o MSBuild para construir o projeto, esse é o trabalho do dotnet-cli.

Se eu estiver usando um editor de texto para adicionar dependências nuget ou arquivos .cs, quais etapas extras devo adicionar, se houver?

Para arquivos .cs, definitivamente nada mais, assim como hoje - a única coisa que eles deixaram muito claro é que os dias de especificação de cada arquivo .cs em seu projeto ficaram para trás (embora provavelmente você ainda possa fazer isso se quiser , olhando para você @ Mike-EEE). Quanto às dependências, certamente no curto prazo (curto prazo sendo meses), elas permanecerão no project.json e funcionarão exatamente como antes. Há uma chance de que project.json se torne nuget.json e, além da mudança de nome, nada mais muda, mas existem outras possibilidades para isso e esta parece ser uma das principais coisas sobre as quais a Microsoft não tem certeza - deixe sua voz ser ouvido em suas preferências para isso.
(Minha preferência pessoal é ser capaz de fazer algo como.nuget.json mas isso é apenas eu cuspindo).

Quando estou revisando um conjunto de alterações em que um usuário do VS adicionou uma dependência nuget e um arquivo .cs, as alterações do csproj serão simples e legíveis por humanos? (Para comparação, com .net 4.6 e VS2015, minha opinião é que as alterações no csproj não são facilmente legíveis por humanos.)

Para o arquivo .cs, o csproj não deve ser alterado. Para dependências nuget - boa pergunta, mais uma vez, isso está um pouco no ar. Realmente não deve fazer com que o csproj mude, mas a grande decisão no momento é se o nuget deve viver no nuget.json ou se o csproj deve ter esse material - e se eles estiverem separados, quão difícil será encurralar os dois?

E esse é o ponto crucial. Quanto menos ferramentas forem necessárias, melhor. Atualmente, posso usar um editor de texto e a linha de comando sem sentir que estou nadando contra a corrente. Espero que isso não mude. No terreno .net46, tenho que editar um arquivo xml gigante e prolixo se não quiser usar o VS, e misturar usuários do VS com usuários não-VS no mesmo projeto é um pesadelo.

Eu concordo total e totalmente com isso, mas a Microsoft investiu muito em seus esforços de plataforma cruzada para repentinamente torná-lo um pesadelo. Por "conjunto de ferramentas", eu suspeito que será para o .net CLI em vez de VS ou qualquer coisa assim. Não se esqueça, o "jogo final" definitivo para o núcleo .net é ser uma plataforma muito ágil e rápida, mas que não o force a perder tempo atualizando a cada duas semanas. Tenho _muito certeza_ de que se você escrever um aplicativo dotnet 1.0 em junho, ele ainda será construído e executado daqui a alguns anos, mas as versões mais recentes serão um caso de execução de "atualização dotnet" ou algo parecido quando estiver pronto . Mesmo quando o RTM é atingido, os projetos RC2 ainda criarão e executarão bits RC2 até que você realmente vá e altere o destino para RTM (acho que em global.json ou em algum lugar?).

: rindo: Quando leio tópicos como esses, fico imaginando se a Microsoft tem momentos de arrependimento. Eu realmente respeito e sinto pelos caras que fizeram e estão fazendo o máximo para virar a Microsoft do avesso, com o objetivo de tornar um paraíso transparente, de código aberto e com a mente voltada para a comunidade para desenvolvedores. Os caras por trás dessa transformação se importam. Eles são os mocinhos. Eles têm que estar entre uma rocha e um lugar duro agora; os sentimentos nada construtivos da comunidade flutuando (enquanto me divertem) não estão ajudando no caso deles.

Gostaria de salientar que substituir um monte de funcionalidade de criação de projeto mágico que existe atualmente no IDE por um aplicativo de linha de comando que faz muita manipulação csproj mágica é uma má ideia. Tornar o arquivo de definição de projeto o mais simples possível é uma obrigação. A melhor parte de project.json é que eu posso ler e entender.

@shederman Seu problema com o MSBuild é que em um sistema grande e complexo ele é grande e complexo ....

Eu também trabalhei com Team Builds e também odiei absolutamente (Pinging @ Mike-EEE porque ambos conversamos sobre como essa experiência é terrível), eu entendo , mas o que você está descrevendo é completamente diferente cenário. MSbuild _pode_ ser grande e complexo e por padrão o VS _torna_ grande e complexo - mas é isso que está mudando .

O arquivo csproj mais recente deve ser muito menor, o que significa que a "Depuração" deve ser bastante simplificada. Nenhum (ou pouco) lixo. Você ainda pode usar qualquer _build system_ que desejar, diabos, você pode chamar um arquivo .bat que apenas chama "dotnet build" em * .csproj e você obterá a saída que deseja, como hoje. Deixe o dotnet cli lidar com o MSbuild e você nem deverá ter que tocá-lo.

@neoKushan não, obrigado.

Eu quero o que foi prometido, não batom no que nos disseram que estávamos nos afastando.

E se você não quer nos dar o que foi prometido, deixe-nos dar a nós mesmos. Já está tudo aí. Deve ser apenas o caso de manter as refatorações. Vou fazer o trabalho, como disse antes.

Suspeito que o principal motivo pelo qual não haja apetite para deixá-lo assim é a compreensão de que este seria o início de uma migração massiva de projetos MSBuild. Sinto muito, mas manter uma tecnologia desatualizada em suporte de vida não é um dos objetivos de design do .NET Core. É isso?

O maior problema com o MS Build é quem vai consertá-lo e quanto tempo leva. No momento, projetos ASPnet inteiros têm mais de 1000 questões abertas, algumas delas realmente críticas. Olhe para SignalR.
Falta um mês para o lançamento, e esses bugs estão muito próximos do estado final.

E agora eles dizem que o ms build pode ser melhorado. O MS tem recursos suficientes para gerenciar toda essa merda de legado 💩? A comunidade pode lidar com isso? Eu realmente não acredito nisso.

@shederman

E se você não quer nos dar o que foi prometido, deixe-nos dar a nós mesmos.

Eles não estão impedindo você de fazer NADA. Vá em frente e garfo, nada o está impedindo. Se você está esperando a permissão da Microsoft, então você já a tem, você a obteve no segundo que eles abriram o código.

Já está tudo aí. Deve ser apenas o caso de manter as refatorações. Vou fazer o trabalho, como disse antes.

Então faça? Novamente, nada está parando você.

Suspeito que o principal motivo pelo qual não haja apetite para deixá-lo assim é a compreensão de que este seria o início de uma migração massiva de projetos MSBuild.

Por que eles se importariam? Que diferença faz para a Microsoft se você usar o MSbuild ou outra coisa?

A razão número 1 real é que a estrutura do projeto do núcleo do ASp.net só é realmente boa para o núcleo do asp.net. Existem centenas de outros tipos de projeto por aí que simplesmente não seriam adequados para project.json. Não importa o fato de que project.json tenha seus próprios problemas, dos quais aparentemente todos esquecemos - a falta de comentários é minha implicância (e não, sugerindo algum-outro-formato-contanto-que-não- XML não ajuda).

Sinto muito, mas manter uma tecnologia desatualizada em suporte de vida não é um dos objetivos de design do .NET Core. É isso?

Não, mas ajudar as pessoas a portar seus projetos antigos e existentes para o núcleo .net é uma meta. Além disso, estamos falando sobre a versão do núcleo .net do MSBuild, não a versão de desktop totalmente desenvolvida, há uma diferença .

Seu único problema é que eles ousaram chamá-lo de MSBuild. Se eles tivessem surgido com um novo estilo de projeto que por acaso fosse XML, mas fosse chamado de "CoreBuild" ou algo assim, você não ficaria sabendo e tudo o que você teria para continuar é "Eu odeio XML!".

você está esperando a permissão da Microsoft, então você já a tem

Não é bem verdade. Não quero fazer fork , quero mantê-lo no repositório principal. Existe uma diferença. Assim, ninguém precisa baixar um SDK .NET totalmente novo. Eu quero isso no ferramental e, para isso, sim, preciso da aquiescência deles.

Seu único problema é que eles ousaram chamá-lo de MSBuild

Não, eles desejam _usar_ o MSBuild. Diferença leve, mas importante. Renomeie o novo sistema de compilação project.json e chame-o de MSBuild e vou usá-lo com prazer.

você não saberia nada e tudo o que você teria que dizer é "Eu odeio XML!"

Talvez 😄

Enfim, andando em círculos.

Indo para a cama.

Eu digo deixar para a trocação. Ninguém está convencendo ninguém. Tenho certeza de que entendo o lado pró-MSBuild, mas não concordo com isso. E tenho quase certeza de que o lado pró-MSBuild entende o lado não-MSBuild, mas não concordo com ele.

Tudo o que estou dizendo é que podemos ter os dois. Por nenhum (ou muito pouco) esforço extra da equipe de MS. Em seguida, deixe as opções afundar ou nadar no brilho do uso real da produção.

Por pergunta de @neoKushan :

O que sobrou?

Na verdade, quero enquadrar minha resposta, se possível, em torno dos "princípios" que delineei acima sobre o que acredito ser um arquivo de projeto bom e utilizável:

• Deve ser editável / legível por humanos

Tomando a declaração de @neoKushan acima para significar que ela será tratada - estou assumindo que alguém na MSFT disse / escreveu isso. Dito isso, quero ver uma proposta baseada no MSBuild em que isso seja abordado primeiro, antes de "comprometer" (como uma comunidade / estrutura) com o MSBuild.

Estou assumindo que livrar-se do Guid ProjectType é um dos principais itens a serem tratados.

Mas mantenho meu adendo acima: é um requisito difícil (não negociável) que, para projetos simples (por exemplo, ASP.Net Hello World em Angular), posso criar tudo à mão, no bloco de notas. Se eu precisar usar Yeoman / VS / similar, falhamos em propor um arquivo de projeto editável por humanos.

• Deve permitir comentários

Já trabalhando, no MSBuild

• Deve ser declarativo

Alterando a ordem do primeiro nível (filhos diretos de) pode mudar todo o significado do projeto, geralmente de maneiras difíceis de depurar. Em nenhum lugar isso é mais notável do que trazer as importações de .targets para o topo por acidente.

• Deve ser independente

Este é o meu maior problema com o MSBuild. Ler um arquivo, estaticamente, não fornece informações suficientes para saber realmente o que está acontecendo nele. De arquivos .targets que vêm de caminhos especificados por _variáveis ​​de ambiente_ e o próprio fato de que as variáveis ​​de ambiente são suportadas por eventos, condicionais e importações, juntos você obtém o que é efetivamente um ambiente Turing Completo, ao custo de um nível muito alto de complexidade e pouca habilidade com as ferramentas. Eu acredito que a integração abismal do VS com o MSBuild é uma consequência da dificuldade de construir ferramentas em torno disso.

Isso é semelhante à preocupação com a legibilidade / edição humana.

• Deve ser projetado para reduzir conflitos de mesclagem / simplificar a mesclagem, se possível

O MSBuild suporta tecnicamente isso na forma de curingas. O suporte do VS para curingas é pior do que abismal. Isso torna mais difícil trabalhar ativamente. Conforme acima, estou disposto a aceitar que isso será corrigido - mas precisa ser um item em uma _proposta_ para _migrar_ (e é uma migração para, porque todas as mensagens até agora eram sobre project.json) para MSBuild arquivos de projeto baseados em

• Deve ser totalmente documentável (com o princípio de autocontenção se aplicando à documentação)

Acredito que o MSBuild tenha documentação. Essa documentação, especialmente para o VS _flavor_ do MSBuild, deixa um pouco a desejar. Muitas vezes fico perplexo por que coisas diferentes estão nos grupos em que estão, e VS "ajudar" a movê-las não é muito útil.

Um exemplo perfeito é o pacote Bond NuGet. Quantas pessoas sabem que, se você não tiver uma pasta BondInclude no disco (se ela for referenciada no csproj), o build irá falhar misteriosamente ao realmente gerar qualquer um dos tipos de Bond no assembly resultante? (Sem spew de erro, também). Em seguida, criar uma pasta vazia com esse nome e recarregar o projeto corrige isso.

(Sim, eu sei, vou registrar um bug nele)

• Deve ser independente de ferramenta

Digamos que eu não queira ter nada a ver com o MSBuild (digamos porque estou me sentindo contrário, sem entrar no assunto mais adiante); Eu só quero definir meu projeto e puxar pacotes via nugget. Por que sou forçado a usar este sistema de compilação específico? Principalmente se eu só quiser definir um projeto?

Um arquivo de definição de construção não é um formato de arquivo de projeto. O fato de o VS ter conseguido fazê-lo funcionar (de alguma forma) não é um bom motivo para continuar a usá-lo dessa forma. Quero um arquivo real que represente apenas o próprio projeto e informações sobre o artefato que ele gera (não instruções sobre como construí-lo). Nisso, mesmo project.json falha porque nos permite definir "comandos". Por que isso existe? Basta definir qual é o tipo de saída e onde pode ser encontrada.

Eu li todo este tópico, e uma coisa que me chamou a atenção nesta discussão de project.json vs project.csproj é que apenas um desses nomes de arquivo tem uma linguagem de programação inteira embutida nele. Eu prefiro fazer o desenvolvimento ASP.NET em F #. Isso é possível no ASP.NET Core? Neste ponto, não tenho a menor ideia, mas tenho a sensação de que não é. Eu nem tenho certeza se as pessoas estão usando csproj como uma abreviação para csproj, fsproj, vbproj ou se elas realmente querem dizer apenas csproj .

Atualização: o pessoal do F # está trabalhando no suporte ao CoreCLR, mas ainda não há um ETA real. Meu ponto é que qualquer sistema de projeto que seja decidido agora afetará linguagens de programação que nem parecem estar no radar das pessoas agora. Por mais que eu prefira JSON em vez de XML, se project.json vai me bloquear em C # (e a ordem dos arquivos na compilação é crucialmente importante em F #), então não sou a favor.

Por enquanto, parece que voltou ao FAKE e ao Paket para mim ...

Trabalho com .NET desde o início e nunca tive problemas dignos de nota com o MSBuild. O principal motivo para isso é que nunca o usei para outra coisa senão para a compilação de solução pronta para o uso.

E é isso que eu não entendo sobre essa antipatia pelo MSBuild. Ninguém força ninguém a usar o MSBuild para outra coisa que não seja a compilação da solução. E eu acho que ser capaz de compilar uma solução é um recurso bastante útil - que BTW nem existe no "dotnet cli" ainda (você tem que fazer um loop manual pelos projetos agora - me corrija se eu estiver errado).

Seu sistema de compilação real não precisa ser alterado. Se você estiver usando o Nant, continue usando o Nant. Se você estiver usando o psake, continue usando o psake. Se você estiver usando um script PowerShell, continue usando-o. Etc! Muito provavelmente, apenas a parte "dotnet build" deve ser substituída por uma chamada para o MSBuild. (Talvez nem mesmo isso seja necessário se a compilação do dotnet chamar o MSBuild)

Eu diria que isso torna o MSBuild um detalhe de implementação sem importância. É assim que tenho visto na última década e é assim que continuarei a ver.

Mas é claro, como já disse no início deste tópico, o que definitivamente precisamos são alguns dos _recursos_ de project.json e Visual Studio para tratar melhor o csproj - e não vejo por que eles não fariam ser capaz de entregar isso.

@jtmueller Não há absolutamente nenhuma razão _técnica_ para que você não possa usar F # (ou VB.net, se quiser). Eu não ficaria surpreso se parte da mudança para arquivos de projeto MSBuild fosse para ajudar a facilitar isso. DNX nunca ficou muito feliz com isso, mas CoreCLR definitivamente suporta F #. Não sei se você poderá usar o F # come RTM, mas está definitivamente no pipeline.

@jtmueller project.json é basicamente uma definição de projeto com manifesto de dependência, além de comandos personalizados. Não há nada vinculado a um idioma específico.

O sistema de compilação dos meus sonhos (para substituir inteiramente o MSBuild) usaria Roslyn para descobrir as tarefas e metas, permitindo que você use F # para definir seu processo de compilação (ou C # ou VB.NET, qualquer coisa que Roslyn suporte).

Claro, ninguém está propondo isso ainda. Mas nos trancar de volta no MSBuild quase certamente fechará essa porta por um longo tempo.

Tive um bom descanso, e pensei um pouco sobre o desafio do que precisa ser feito para "salvar" o MSBuild. Não acredito que possamos ou devamos transformar o MSBuild em um sistema de compilação significativamente diferente. É um sistema de construção definido por XML baseado em inferência e que funciona para ele, e para muitos cenários de pessoas, especialmente alguns dos cenários mais complexos.

Mas nem todos nós temos Build Masters dedicados que podem entrar em conflito com o MSBuild. Nem todos nós precisamos do poder que a complexidade do MSBuild traz. Algumas das pessoas que precisam que a complexidade não quer usar MSBuild. Em uma de minhas equipes, por exemplo, toda a lógica de compilação personalizada é feita nas etapas pré e pós-compilação, o Exec é essencialmente shell para o Powershell. Não porque não possa ser feito no MSBuild, pode e, nesse caso, provavelmente _deve_. Mas porque eles não querem fazer isso no MSBuild.

O primeiro passo é definitivamente que precisamos separar a definição do projeto do sistema de compilação. Para mim, isso faz muito sentido. Podemos discutir a divisão de dependências fora da definição do projeto, mas não acredito que seja necessário.

O segundo passo é que precisamos de um sistema de construção. Precisamos lidar com casos de uso muito simples, bem como casos altamente complicados. Mas nenhuma regra diz que um sistema de construção tem que lidar com _both_. Na minha opinião, o que faz mais sentido é ter um sistema de construção simples e leve que basicamente constrói a definição do projeto. Ele faz restore , build , test e pack .

Acho que devemos também procurar uma maneira de funcionar _sem_ uma definição de projeto, usando a estrutura de diretórios como definição. Obviamente, tal situação significaria que ele usaria a estrutura padrão e as dependências padrão. Talvez seja possível, talvez não. Mas podemos olhar para cada elemento na definição e perguntar "podemos inferir um padrão inteligente para isso"?

Mas embora isso provavelmente seja suficiente para 80% dos casos de uso, não é suficiente para os outros 20%. Eles precisam de algo mais. (advertência: as opiniões sobre as taxas de casos de uso podem variar).

O terceiro passo é permitir uma forma muito simples de extensibilidade a esse sistema de compilação. Mas estamos falando muito simples. Basicamente, ele pode executar sua compilação básica ou um sistema de compilação externo. O referido sistema de compilação externo pode ser MSBuild, ou scripts, ou algum outro sistema de compilação.

Estou feliz que o novo processo de compilação deva ser desembolsado para o MSBuild, mas não acredito que algo tão (IMO) antigo, rabugento e inchado como o MSBuild deva ser a base para todas as compilações no futuro.

Com coisas como estruturas da Web, vemos as equipes de MS iterando freneticamente. Porque eles têm competição. Eles têm que se preocupar com Nancy respirando em seus pescoços, por exemplo. É _fácil_ mudar para outra coisa. E isso torna o MVC / WebAPI melhor para isso.

Com o MSBuild integrado a todas as ferramentas .NET, é difícil usar qualquer outra coisa. Onde está a competição? E você pode ver os efeitos disso na placa do MSBuild Github. Basta revisar todas as propostas fechadas. A única razão pela qual eles estão falando sobre fazer essas mudanças "diminuindo" agora é porque eles querem que as pessoas mudem de project.json para MSBuild.

Se o MSBuild tivesse sido incorporado ao .NET Core desde o início, acredito que não veríamos _nenhum_ do movimento que estamos vendo agora da equipe do MSBuild. Mas o que acontece quando estivermos trancados de volta? Uma vez que a competição é basicamente excluída? O que vai acontecer? O que sempre acontece em cenários sem competição, e o que tem acontecido por anos até agora: melhorias apenas o suficiente para impedir deserções em massa, mas nada de particularmente interessante.

As pessoas me perguntaram como acho que podemos "salvar" o MSBuild. Acredito que abri-lo para uma verdadeira competição e escolha é o único caminho. Aplicá-lo por decreto a todos os desenvolvedores, mesmo aqueles que não precisam de nada tão poderoso (sim, acredito que seja poderoso), só gerará ainda mais ressentimento contra ele.

Essa não é uma receita para o sucesso de qualquer estrutura.

Por favor, todos, tenham em mente, todos nós queremos que o .NET tenha sucesso. Eu _adoro_ .NET, acho que C # é uma das melhores linguagens de programação que existe, e gostei de sua lenta transição para Scala - The Good Parts ™ 😉.
Não acredito que comecemos de novo com o .NET Core e o façamos acorrentando a uma das (IMO) as piores partes do antigo .NET. Sim, MSBuild, mas não, não preso a ele.

Por suposto, mantenha-o, mas não na frente e no centro embutidos no núcleo do sistema.

O sistema de compilação dos meus sonhos (para substituir inteiramente o MSBuild) usaria Roslyn para descobrir as tarefas e metas, permitindo que você use F # para definir seu processo de compilação (ou C # ou VB.NET, qualquer coisa que Roslyn suporte).

YAAAAAAAAAAS !!! Falando nisso ... este é o lugar certo para ter essa conversa? Temos os repositórios Roslyn e MSBuild também e parece que eles também deveriam estar envolvidos. Acho que estamos testando no repositório MSBuild, mas eles são (como você mencionou) muito rígidos e inflexíveis. Acho que ter mais pessoas aqui como o interesse que esse tópico gerou pode ser um grande passo para a reforma.

O terceiro passo é permitir uma forma muito simples de extensibilidade a esse sistema de compilação.

Um sistema / modelo de compilação baseado em provedor ?! GÊNIO! Eu aprovo esta mensagem.

A propósito, se você realizar o seu desejo e tiver acesso ao seu próprio sistema de construção, sugiro que chamemos de ... BERSERKER BUILD! Nomeado após "Berzerker @shederman" ... meu novo apelido para você. :sorriso:

@ Mike-EEE Não fique muito animado. De maneira nenhuma estou propondo algo tão drástico quanto tudo isso _ainda_.

Por enquanto, acho que devem ser apenas as etapas um e dois, com suporte do MSBuild para a etapa três.

Mas esse tipo de possibilidade é o que eu pensei que estávamos nos movendo quando obtivemos o project.json, separando o projeto do build para que fosse mais fácil trocar provedores de build. Em minha opinião, trazer o MSBuild de volta à raiz fecha essas possibilidades. Ou, pelo menos, torna-os muito menos propensos a obter tração.

No momento, os builds personalizados não ganham adoção porque o sistema raiz _é_ muito poderoso. É uma conversa difícil convencer as pessoas de que você deseja usar um sistema de compilação não-MS quando o sistema de compilação MS pode realmente fazer tudo o que é necessário (ignorando a dor).

este é o lugar certo para ter essa conversa

Acho que não, não. Além disso, não pense que sabe que ainda é o momento certo. Precisamos resolver esse problema antes de ver quais direções são possíveis.

BERSERKER BUILD! Nomeado após "Berzerker @shederman" ... meu novo apelido para você. :sorriso:

Não tenho certeza de como me sentir sobre isso 😉

Não tentando ser um berserker. Só não quero retroceder quando _estamos_ avançando.

Ei pessoal, talvez em vez de reinventar a roda ( nuget.json ou como vai ser chamado) vamos usar a solução existente, dirigida pela comunidade que está resolvendo a maioria dos problemas de gerenciamento de dependência - Paket .

1. Tem conceito de dependências transitivas
2. Está bem integrado com MsBuild
3. Possui formato de arquivo legível por humanos para definir dependências
4. Tem um caminho de migração muito bom de packages.config
5. E muitos outros recursos (mas aparentemente esses 4 são as coisas mais importantes para todos, então não mencionarei coisas como dependências do Git ou melhor estratégia de resolução de pacote)

@ Krzysztof-Cieslak lembre-se de que a maior razão pela qual a Microsoft está promovendo as definições de projeto do MSbuild é para ajudar a facilitar a migração daqueles que investiram muito no MSBuild. Nesse sentido, Paket não é melhor que project.json (ou project.yaml ou project.cs ou qualquer outro).

Dito isso, ainda não vejo nenhuma razão pela qual você não pode usar qualquer sistema de compilação que deseja. No final das contas, "dotnet build" não vai mudar, independentemente do formato que a definição de seu projeto acaba sendo, dotnet build ainda irá gerar sua saída.

@neoKushan Sim, mas o "dotnet build" exigirá um arquivo MSBuild mesmo se não estivermos usando o MSBuild? Ele será compilado se não houver nenhum arquivo MSBuild? Ou irá desembolsar para o MSBuild que irá então desembolsar para qualquer outro sistema de compilação usado?

@shederman Sem dúvida, o "dotnet build" usará o MSBuild em segundo plano para realmente construir os projetos, mas se realmente vemos ou não algo disso está muito no ar. Atualmente, hoje, você precisa de um project.json para construir corretamente seus projetos, se não para referências, então para outros dados importantes (como frameworks de destino). Eventualmente, parte (ou mesmo tudo) disso irá migrar para um arquivo csproj, portanto, presume-se que você precisará desse .csproj para que a compilação do dotnet funcione, não importa o que ele use em segundo plano. No entanto, quanto impacto isso realmente tem para você ainda está para ser visto.

Como eu disse, contanto que eu tenha permissão para fazer o trabalho, manter a construção leve no lugar, que não requer nenhum MSBuild, estou feliz. Vocês podem construir seu pipeline auto-referencial "MSBuild em todos os lugares" em qualquer beco sem saída que quiserem.

Mas se isso funcionar, então csproj precisará incluir project.json como RichiCoder sugeriu .

Dessa forma, o "core build" e o "MSBuild" podem funcionar lado a lado, ou o core build pode funcionar sem o MSBuild. E, obviamente, se você não importar o project.json, você pode definir as propriedades do seu projeto no csproj também.

Uma mudança bem fácil, na verdade. Do topo da minha cabeça, precisamos:

• Mantenha o código de compilação dotnet existente e execute-o em certas circunstâncias (a serem determinadas).
• Em outros, execute o MSBuild, de acordo com os planos das equipes centrais do DotNet
• Ter o VS capaz de ler project.json ou MSBuild para propriedades do projeto
• Adicionar capacidade de importar project.json para MSBuild

É muito trabalhoso e permite que a Microsoft continue seu caminho "MSBuild para sempre", além de cumprir as promessas feitas à comunidade .NET Core e permite que aqueles de nós que desejam cancelar o MSBuild o façam.

É notável que ninguém dos membros do asp.net tenha dito nada aqui.

Enquanto isso, eu reli algumas das notas do ASP.NET Community Standup - 10 de maio de 2016 , e eles falam sobre um "novo" sistema MSBuild, mas não diga o que é, exceto que não exigirá Visual Studio para editar. É uma pena que não foi projetado no asp.net e tem que ser adicionado (agora) tão tarde no jogo ... quando o design não incluía isso para começar. Na verdade, project.json deve incluir apenas um item {"BuildSystem": "MSBuild"} se você quiser / precisar seguir esse caminho. Também me pergunto por que o MS não pôde (últimas palavras famosas) "simplesmente" permitir comentários em arquivos json por meio das ferramentas.

@rhires Pelo que entendi, o "novo" sistema MSBuild são alguns ajustes para tornar o XML um pouco mais leve, como incluir todos os arquivos cs na construção e transferir as dependências para um arquivo nuget.json. Nenhuma mudança significativa no design, arquitetura ou uso do MSBuild.

Gosto da sua ideia project.json. Estava apenas passando pelas mudanças do RC2, e eles colocaram o "testrunner", então não há razão para que isso não possa ser feito. _BUT_, parece que seus corações estão totalmente decididos a remover inteiramente o project.json e voltar a um mundo que prioriza o MSBuild.

por que o MS não pôde (últimas palavras famosas) "simplesmente" permitir comentários em arquivos json por meio das ferramentas

Não há razão para que eles não pudessem. JSON.Net, a biblioteca que eles usam, apóia comentários.

Na verdade, project.json deve incluir apenas um item {"BuildSystem": "MSBuild"} se você quiser / precisar seguir esse caminho.

Por que eu iria querer que meu projeto ditasse seu próprio sistema de construção? Certamente o sistema de compilação constrói o projeto e não o contrário?

@neoKushan :

lembre-se de que o principal motivo pelo qual a Microsoft está promovendo as definições de projeto do MSbuild é para ajudar a facilitar a migração daqueles que investiram muito no MSBuild. Nesse sentido, Paket não é melhor que project.json (ou project.yaml ou project.cs ou qualquer outro).

Paket não é um novo sistema de build, é um gerenciador de dependências 100% compatível com MsBuild. Isso apenas resolve o problema de packages.config .

@ Krzysztof-Cieslak Eu nunca afirmei que era um sistema de construção e gerenciamento de dependências não é realmente um grande problema com o núcleo .net (pelo menos pelo que eu sei). .net core não usa packages.config ele usa project.json .

Se o .Net Core ainda estivesse planejado para usar project.json , não teríamos essa discussão de 100 postagens. ;) Tudo o que estou dizendo é que a solução sugerida em muitos lugares de usar "nuget.json" para lidar com dependências é reinventar a roda, pois temos um produto que faz exatamente o mesmo.

@shederman

"Resultados finais da pesquisa: 100 respostas, para uma população de desenvolvedores .NET de 9 milhões de ± 10% com 95% de confiança."

Sim, e perguntar em uma conferência sobre brinquedos para gatos qual é o animal de estimação preferido de um cachorro ou gato pode fornecer resultados semelhantes.

@darrelmiller

"Acho que é importante fazer uma distinção entre o MSBuild e a maneira como o Visual Studio usa o MSBuild atualmente. Tenho editado manualmente os arquivos do MSBuild há anos e os uso para todos os meus projetos. Por exemplo, https://github.com/tavis- software / Tavis.home / blob / master / build / Build.proj "

Devemos discutir os arquivos de construção específicos do VS sobre os arquivos de projeto em que o msbuild não funciona na linha de comando?

@gregoryyoung Devíamos. Já criei arquivos que dependem do devenv antes, mas não vi nenhum que não fosse executado na linha de comando. Algum exemplo?

@gregoryyoung

Sim, e perguntar em uma conferência sobre brinquedos para gatos qual é o animal de estimação preferido de um cachorro ou gato pode fornecer resultados semelhantes.

Essa é uma analogia interessante. Exceto...

Publiquei o link nos feeds do Twitter de pessoas que _suportaram_ a mudança para o MSBuild. Então, na verdade não é nada parecido com a sua analogia.

E adoro os insultos constantes de que a pesquisa foi parcial, no fórum errado ou não científica. Mas, as perguntas não conduziam, as respostas tinham uma ampla gama de respostas, e a pesquisa, sim, era um público autosselecionado, mas amplo que, pelo menos em teoria, deveria se afastar do meu ponto de vista.

Também tenho a impressão, e em alguns casos a confirmação, de que as pessoas que fazem essas acusações acabam de pesquisar no Google um pouco sobre pesquisas. Eu, pessoalmente, projetei um protocolo de pesquisa de nível de mestrado para um estudo de saúde e, embora não afirme que a pesquisa é perfeita, certamente não é tão falha quanto os funcionários da Microsoft estão fingindo.

Certamente _é_ estatisticamente significativo e está lhe dando uma boa indicação de onde se encontra a opinião. O GitHub, o gitter, o Twitter e os blogs estão apoiando isso em um grau ou outro.

Múltiplas fontes de evidência dizendo a mesma coisa. Se você deseja ignorar as opiniões de um significativo de seus usuários, diga isso. Pare de tentar afastar a oposição deles, como se você perdesse o direito de expressar sua opinião se defender a opinião "errada".

Ou melhor ainda, como já disse muitas vezes, crie sua própria pesquisa que melhore as coisas que você acha que estão erradas com a minha.

A razão pela qual fiz a pesquisa é que estava absolutamente claro que a Microsoft não fazia ideia do que as pessoas estavam pensando. O que está se tornando totalmente claro agora é que eles não têm _interesse_ no que as pessoas estão pensando.

Pare de ser desonesto consigo mesmo e com sua comunidade e se envolva com a oposição em vez de rejeitá-la.

Pare de tentar mudar os fatos e comece a mudar de ideia com base nos fatos.

@shederman Não tenho a impressão de que a equipe da Microsoft realmente respondeu a este tópico (incluindo sua pesquisa). Sim, um cara da equipe disse que não o considerava tão confiável quanto você, mas isso é tudo. Acho que ainda há esperança de que eles estejam falando sobre a oposição massiva ao caminho que estão trilhando e discutindo sobre o curso certo a seguir e responderão a nós quando souberem mais.

Acho que podemos dar algum crédito a esta equipe;).

@gregoryyoung Desculpe, pela analogia que você deu, presumi que você fosse um funcionário da MS, já que eles estão usando a mesma linha aproximada há 2 dias.

@sandorfr

Acho que podemos dar algum crédito a esta equipe

Achei que poderíamos, mas minhas experiências nos últimos dias não reforçaram essa esperança.

Tenho que pensar que não é "culpa da equipe", mas de alguém de alto escalão na organização que tomou essa decisão e a impôs ... e então "a equipe" tem que engolir e fazer com que pareça bonito. BTDT. Não tem graça.

Todos vocês perceberam que project.json já passou por grandes mudanças recentemente para torná-lo um pouco mais compatível com aplicativos não ASP.NET Core? Se você apenas olhar para o exemplo naquele post de anúncio, ele já está bastante inchado com toda aquela configuração de construção.

Ir para um arquivo csproj “clássico”, na verdade, não parece ser um exagero para mim. E se o próprio csproj também evolui um pouco na direção mais flexível que aprendemos com o project.json, na verdade posso ver o csproj “novo e aprimorado” funcionando muito bem. E acho que podemos presumir com segurança que essas mudanças recentes no project.json não teriam sido as últimas no curso a torná-lo utilizável para _todos_ os tipos de projetos .NET — acho importante não nos esquecermos de que há há muitos outros destinos além do ASP.NET (Core).

E, na verdade, não deve importar muito se o formato do arquivo é JSON, XML ou qualquer outro. Sim, um pode ser favorável a outro por vários motivos válidos, mas no final você deve pensar em quanto tempo realmente deseja gastar em um arquivo de projeto . Sim, com os problemas que vivenciamos com os formatos atuais, gastamos mais tempo do que gostaríamos, mas o ideal é, supondo que consertemos essas causas, deveríamos gastar uma fração incrivelmente minúscula de nosso tempo nesses arquivos. E, nesse momento, você realmente não precisa se preocupar com o formato em que está. Especialmente se for todo assistido por ferramenta (incluindo preenchimento completo nos editores).

Eu sinto que quando as pessoas pensam sobre project.json, elas pensam principalmente sobre os estágios iniciais, que eram muito sobre convenção em vez de configuração. Sim, isso foi muito bom, mas também muito específico para o ASP.NET Core e, como tal, muito limitado. Realmente não funcionará bem para outros alvos, então faz sentido usar algo que tem funcionado bem por muitos anos e expandi-lo e melhorá-lo de todas as maneiras possíveis, mantendo a compatibilidade.

Portanto, tl; dr: Sim, eu realmente gosto de project.json e gostaria que houvesse uma maneira de mantê-lo para ASP.NET Core (por exemplo, usando uma tarefa MSBuild especial). Mas, ao mesmo tempo, entendo perfeitamente por que isso está acontecendo agora e acho que não é uma coisa ruim que eles façam. Claro que o tempo é um pouco estranho, mas dado que a mudança não acontecerá paralelamente ao lançamento do ASP.NET Core e .NET Core, não acho que o tempo seja um problema real (presumindo que a transição posterior será suave )

necessidade de ser capaz de compartilhar arquivos de origem entre projetos

@darrelmiller Isso parece assustador para mim, porque parece implicar que a listagem de arquivos no .csproj está voltando.

@lokitoth Supondo que o csproj funcione de forma semelhante para referências de arquivo como o project.json mais recente, não há nada que o impeça de usar globs em geral e ter referências de arquivo individuais junto com eles.

@shederman Não sou um funcionário da MS, apenas uma pessoa racional. Se você me pesquisar no Google, tenho certeza de que descobrirá que tenho um interesse de longo prazo na plataforma.

Existem muitos prós / contras associados à mudança, mas o que você forneceu não é útil para nenhuma discussão sã.

Esta foi uma mudança decepcionante de se ouvir. project.json, inclusão / globbing automático de arquivo e restauração transitiva foram as primeiras coisas sobre o ASP.NET Core que me fizeram dizer "ah, legal!" no inicio.

Sei que nem tudo isso iria desaparecer (espero?). Mas voltar para um arquivo de projeto XML parece ruim, porque historicamente isso significa dores de cabeça para os humanos. Eu odeio abrir um arquivo csproj para corrigir um problema porque é uma parede de texto difícil de analisar.

Apenas meus dois centavos.

Olhando para as mudanças na postagem de

Com base no fato de que eles desejam oferecer suporte às opções Compile, Embed, CopyToOutput, Exclude, Shared Files etc., o formato json não funcionaria melhor do que XML de qualquer maneira. Também suspeito que json não teria funcionado tão bem para personalizações de script de construção pesada.

Só espero que esta seja a equipe tentando não adicionar outra solução incompleta à produção até que tenham tempo para descobrir uma maneira de fazê-lo bem.

@gregoryyoung o que você forneceu não é útil para nenhuma discussão sã

Excelente. Ok, vamos ver, o que eu forneci:

• Reclamei sobre a mudança para XML, assim como uma grande quantidade de outros
• Reclamei sobre a mudança para o MSBuild, assim como muitos outros
• Eu tentei entender as razões e evidências por trás da decisão, que não foram fornecidas além de algumas coisas muito onduladas
• Tentei chegar ao _pensamento_ subjacente à decisão, que _também_ não foi realmente fornecido
• Eu pedi a opinião da comunidade, o que a MS não se preocupou em fazer
• Tentei encontrar alternativas que permitissem os resultados declarados pelas pessoas que deram as razões, mas também permitissem que a comunidade mantivesse seu processo de construção simples de que gostam
• Eu me ofereci para fazer o trabalho necessário a fim de apoiar as referidas alternativas

Posso perguntar, sem interesse, qual é a parte insana? Interrogar o pensamento de alguém não é racional hoje em dia? Ou deixei algo lá fora?

Quer dizer, estou com raiva , não me entenda mal. Perdi uma grande quantidade de trabalho, tempo e dinheiro construindo em torno de uma promessa central da estrutura que foi arrancada no último minuto no que parece ser uma ação precipitada e mal planejada. Eu não tenho o _direito_ de ficar com raiva?

PS. Ah, você é _aquele_ Greg Young. Respeito. Ame seu trabalho. Eu realmente quero.

@bzbetty Concordo totalmente com você. A última coisa que eu gostaria de ver é uma reformulação do MSBuild em project.json. Um dos maiores problemas com o MSBuild em sua forma atual é que ele confunde uma _definição de projeto_ com um _processo de construção_.

Portanto, adicionar um processo de construção em project.json seria cometer exatamente o mesmo erro que o MSBuild / VS cometeu.

A definição do projeto deve ser separada do processo de construção e ser alimentada no processo de construção.

E então é preciso perguntar: se o seu projeto é simples e precisa apenas construir diretamente a definição do projeto, você realmente precisa de um sistema de construção pesado, extensível, personalizável, flexível e contra-intuitivo apenas para fazer uma construção simples?

Colocando de outra forma. Se você _tinha_ uma definição de projeto tão simples e uma ferramenta de construção muito simples que não pudesse fazer nada mais do que construir a definição do projeto, você escolheria instalar e usar um MSBuild ou um NAnt ou algo semelhante?

Não, provavelmente não, certo? Quero dizer, por que adicionar desnecessariamente à complexidade. Uma parte essencial da prática eficaz de engenharia de software é manter as coisas simples.

Mas, quando você atinge um cenário que a ferramenta simples de "construir a definição" não consegue lidar? Claro, _então_ você faria.

Estou dizendo, instale as duas ferramentas lado a lado, para que possamos escolher qual é a melhor para nossas necessidades. A MS está dizendo: não, você só precisa da ferramenta complexa e contra-intuitiva, mas removeremos os recursos mais flagrantemente ruins.

Soapboax

Eu só gostaria de compartilhar um pouco de pesquisa que venho fazendo. Tenho pesquisado o Twitter, Slack, Github, Gitter e Jabbr.

Tenho visto muito pouco apoio para a mudança fora da equipe principal. Quer dizer, houve alguns, mas não muito. A maioria das pessoas está muito chateada com a mudança.

Também fiquei bastante consternado com a tendência de muitos no campo pró-MSBuild de inferir que seus oponentes estão mal informados ou, mais comumente, não qualificados. Isso foi correspondido pela tendência do campo pró-project.json de inferir motivos ruins (eu inclusive, mea culpa).

Eu gostaria de perguntar o seguinte:

• As pessoas devem presumir que as pessoas que têm opiniões diferentes das suas têm boas razões. Eles não são iludidos, incompetentes, cúmplices ou loucos
• Pessoas para atacar argumentos e evidências e não pessoas
• Qualquer evidência fornecida não deve ser descartada imediatamente sem motivos firmes

Argumentos para
Os principais motivos que tenho visto avançado para a mudança para o MSBuild são:

• Suporte de ferramentas - Para permitir viagens de ida e volta entre diferentes ferramentas, por exemplo, VS, VSCode, Xamarin, etc.
• Investimentos existentes - grandes clientes têm construções existentes que não podem ser jogadas fora
• "Memória muscular" - as pessoas estão acostumadas com o MSBuild

Argumentos contra

• Investimentos existentes - investimentos feitos em ferramentas .NET Core: pós RC. RC _deve_ significar sem grandes mudanças significativas
• CSProj / MSBuild desagradável - experiências negativas anteriores ao lidar com csproj e MSBuild
• Recuar - Mover para project.json foi mover para uma nova maneira de trabalhar, em parte para atrair uma nova geração de desenvolvedores. Isso está sendo desfeito

Opinião
Eu paguei por uma assinatura completa do SurveyMonkey para que eu possa acessar o conjunto completo de resultados (em vez do primeiro cem). São 321 respostas, o que normalmente se traduziria em uma margem de erro de ± 5,5%, com 95% de confiança para uma população de 9 milhões.

Os argumentos comuns que ouvi contra esta pesquisa são:

• As perguntas / respostas são tendenciosas: não acredito nisso, e mesmo que sejam, não são muito. Existe uma ampla gama de respostas.
• A pesquisa foi postada para um público tendencioso: Twitter? Para os seguidores dos vários cronogramas dos membros da equipe. Não tenho certeza de como esse é um público tendencioso.
• Não é cientificamente relevante: Ok, me pegou nessa. Eu não fiz um protocolo de pesquisa completo, então não seria aprovado na revisão por pares. Esse é o nível de certeza necessário para avaliar o apoio a uma proposta?

Aqui estão eles:

Meu apelo a todos que amam a estrutura .NET é que não subestime o nível de angústia sobre essas mudanças e leve o feedback em consideração e se envolva com a comunidade sobre isso, com base no fato de que suas preocupações são válidas e vêm de uma experiência informada .

E se a decisão for ir em frente de qualquer maneira, um conjunto melhor de raciocínio e evidências deve ser fornecido do que tem sido até agora.

Man @shederman me lembra de mim (e de muitos outros) quando o Silverlight o comeu , exceto x10 e mais focado / experiente. Provavelmente é por isso que eu o apoio: 100:%! haha.

Um dos maiores problemas com o MSBuild em sua forma atual é que ele confunde uma definição de projeto com um processo de construção.

Portanto, adicionar um processo de construção em project.json seria cometer exatamente o mesmo erro que o MSBuild / VS cometeu.

A definição do projeto deve ser separada do processo de construção e ser alimentada no processo de construção.

: +1:: +1:: +1: ... Excelente forma de enquadrar o problema !!! Sabe, estou metido nisso há tanto tempo que isso nunca me ocorreu realmente. Mas você está (novamente) 100% certo.

Eu odeio abrir um arquivo csproj para corrigir um problema porque é uma parede de texto difícil de analisar.

Isso precisa ser enquadrado em algum lugar, @nbarbettini! Captura perfeitamente meu sentimento também.

E, na verdade, não deve importar muito se o formato do arquivo é JSON, XML ou qualquer outro.

Sim, odeio tentar lembrar as pessoas disso, mas parece que alguns desenvolvedores estão presos à noção de formatos, e isso é enganoso. O paradigma de projeto "JSON" não é realmente uma "coisa JSON", mas usa JSON como sua escolha de serialização para descrever seu "modelo". O fato de JSON ser conciso e menos falador do que XML o tornava ainda mais atraente (para a maioria).

Da mesma forma, o MSBuild não está enraizado no XML, por si só, mas a maneira como foi projetado é ter seu "modelo" descrito neste formato. Digo "modelo" porque ambos os sistemas sofrem de uma (o que considero uma) falha de design de colocar um modelo de documento na frente do modelo / API real que, em última análise, é desserializado na memória. Isso significa ter que gerenciar mais artefatos e conceitos do que o realmente necessário e, em última análise, complica o sistema. Codificá-lo para aceitar apenas um formato específico (XML ou JSON) só piora e, novamente, devemos explorar maneiras de atenuar essa restrição.

De qualquer forma, PSA de domingo de manhã coxo para todos. : stick_out_tongue:

Não consegui ver isso postado em nenhum lugar deste tópico, então aqui vai ... https://youtu.be/N9MteJH-HsQ. Esperançosamente, isso explica um pouco mais sobre por que a mudança está sendo feita.

@shederman

"Posso perguntar, sem interesse, qual é a parte insana? Interrogar o pensamento de alguém não é racional hoje em dia? Ou eu deixei algo lá fora?"

Eu estava me referindo aos resultados da pesquisa e tentando extrapolar para a população geral de desenvolvedores. Como mencionei, é mais ou menos equivalente a fazer uma enquete sobre quais cães e gatos são melhores em uma convenção de brinquedos para gatos e, presumindo que isso se aplica à população em geral, há um viés de amostra grande e óbvio.

O GitHub no meu telefone não permite que eu marque com +1

A equipe explicou que parte do motivo da mudança é a aquisição da Xamarin, que é um grande negócio. O potencial para compartilhar bibliotecas entre os projetos .NET, ASP.NET e Xamarin mobile / x-plat é imenso, e se isso significa comprometer o formato do arquivo de projeto / compilação, é uma troca válida IMHO.

Vou esperar para ver como estão as ferramentas e a configuração do arquivo final antes de formar uma opinião final.

@gregoryyoung Eu estava me referindo aos resultados da pesquisa e tentando extrapolar para a população geral de desenvolvedores ... há um viés de amostra grande e óbvio.

Qual seria o viés de amostra? Aquele em que foi postado principalmente nos feeds do Twitter de pessoas que gostaram das mudanças? Aquele em que estava nos canais vagos que a equipe de desenvolvimento usa?

O principal viés de amostra que vejo é que os entrevistados provavelmente são engajados, informados e apaixonados. Claro, essa provavelmente não é uma amostra representativa, mas eu diria que é importante. E mesmo com viés de amostra, isso significa que os resultados devem ser jogados fora? Que os pontos de vista dos entrevistados não importam?

322 desenvolvedores .NET profissionais expressaram uma opinião. Você vai ignorar a entrada deles totalmente porque acredita (sem nenhuma evidência para apoiá-lo) que não é representativa?

Aparentemente, um post no blog virá na próxima semana, teremos coisas mais específicas para discutir então.

Caramba, as pessoas precisam se acalmar :)

Concordo que essa mudança parece grande, mas acho que afetará muito menos as pessoas do que pode parecer. Lembre-se que quando a equipe fala em "ferramental" isso inclui também o cli. Qualquer conversão que precise acontecer também será feita pelo cli, "ferramentas" para adicionar referências, que eu defendo ser ainda melhor do que digitá-las em json ou xml, estará no cli. Globbing já é suportado no msbuild. O Msbuild obviamente será incluído no don't sdk, então não haverá instalações adicionais, a nova história do projeto também será a mesma, os comandos dotnet farão outras coisas por baixo do capô. (Eu não sou um microsoftie, mas isso parece altamente provável)

O time não é idiota, eles não fazem essa mudança levianamente. Eles _teram_ razões, principalmente compatibilidade e coerência com o resto da plataforma entre linguagens, referências nativas e tipos de projeto, granularidade de pacotes nuget e assim por diante. Faz apenas uma semana e eles disseram que irão detalhar as mudanças e seu raciocínio muito em breve.

Eu gostaria que as pessoas pelo menos esperassem por isso e quais são seus planos reais antes de condenar a mudança completamente.

E sim, eu depurei manualmente os arquivos csproj / tfproj e lutei contra regras condicionais para inclusão de arquivos e tudo mais. Caramba, eu até escrevi tarefas de construção personalizadas. Mas, no final do dia, é muito mais fácil abstrair um sistema complexo com ferramentas simples (cli incluído), em vez de fazer com que o sistema relativamente simples project.json suporte todos os cenários complexos de que precisa.

Colocando de outra forma, aquela simplicidade que as pessoas amavam em project.json já havia acabado, ela precisava ir para suportar a realidade complexa de um ambiente dotnet generalizado com todos os tipos de projetos e cenários. Se eles tivessem implementado tudo isso em project.json, você basicamente teria msbuild novamente. Eu prefiro muito mais que eles dêem um passo para trás e olhem para o sistema de compilação como um todo, em vez de adicionar recurso após recurso para project.json até que se torne uma grande bola de spagetti

Vamos ver o que eles estão sugerindo e, em seguida, levantar questões específicas se encontrarmos alguma falha nisso :)

@ aL3891

Se a equipe explicar claramente seu raciocínio e as alternativas que foram consideradas, e por que foram rejeitadas, e também considerar e se envolver com as propostas que foram sugeridas aqui, então estou bem ao lado disso e apoiarei qualquer solução bem fundamentada que sai de tal processo.

Na verdade, é exatamente isso que venho pedindo há três dias. Visão do processo de tomada de decisão e as evidências que o sustentam. As informações fornecidas até agora a esse respeito foram, na melhor das hipóteses, desanimadoras.

Se conseguirmos, +10 de mim.

@ aL3891 Pergunta rápida. Algumas pessoas estavam dizendo que deveríamos comparecer ao levante de quarta-feira para tratar dessas questões. Você está dizendo que devemos esperar pela postagem do blog?

Todos também devem se lembrar de que tudo isso é código aberto. Se você acredita que o não-msbuild é melhor, apenas bifurque o conjunto de ferramentas existente e mantenha-o funcionando. Como acontece com todas as opções de design de software interessantes, há prós e contras em todos os lados do argumento. A Microsoft precisa ser receptiva aos seus grandes clientes pagantes, mas, para seu crédito, eles tornaram todas essas coisas de código aberto. Se algo mais funcionar para você, faça-o.

Eu assisti aquele vídeo do youtube que @khellang postou - as alterações do ASP.NET foram _revolucionárias_, mas parece que, no final, foi muito revolucionário e agora com Xamarin na mistura, _revolucionário_ não vai resolver.

Além disso, a ideia de reinventar a roda não parecia atraente, quando parecia que era realmente a coisa certa a fazer ... mas legado novamente.

Tenho uma crítica recente ao uso do MSBuild, com base no .NET standup - embora tenhamos uma boa separação de interesses em vários lugares, o MSBuild não. Grosso modo, de acordo com o standup, de alguma forma ele precisa saber de tudo para ser eficaz, e meramente orquestrar peças diferentes não é o suficiente.

Enquanto isso, estou pensando que isso deveria ir para outro tópico - parece que há "decisões de engenharia interna" que mais tarde são compartilhadas com a comunidade. Isso me faz pensar que o MS não tem código aberto completamente - se eles tivessem essas discussões abertamente (e alertassem as pessoas de que elas estavam ocorrendo), teria sido menos surpreendente e poderíamos já ter respostas, e muitas partes interessadas (e quero dizer os clientes que seriam afetados negativamente por uma mudança do MSBuild) poderiam ter feito suas posições claramente conhecidas mais cedo, e a comunidade poderia ter reagido de forma mais oportuna sobre os problemas / preocupações e até mesmo soluções para o problemas apresentados ... Em vez disso, "era nossa única opção", é por isso que você abre o código-fonte não apenas do software, mas também do processo de desenvolvimento. É assim que a máxima "com olhos suficientes, todos os insetos são superficiais" deve funcionar. Eu não sei o quão grande é a equipe de engenharia da MS, mas ela é menor do que a comunidade geral, e há alguns talentos realmente bons na comunidade que podem estar prontos para um desafio como aquele que a equipe de engenharia decidiu ser impraticável ... e provavelmente é para eles, mas não para a comunidade em geral. O código aberto significa usar os recursos inexplorados e o talento que existe.

Por outro lado, talvez eu tenha perdido algo em algum lugar?

@shederman, eu sugeriria que aqueles com interesses particulares participem do standup e fiquem de olho na postagem do blog (que quase certamente terá um link aqui).

Para quem não sabe do standup, acesse: https://live.asp.net/

Você pode adicioná-lo ao seu calendário e vale a pena assistir, mesmo se você não se importar com a mudança na definição do projeto.

@shederman Não sinto que realmente tenho autoridade para dizer a ninguém o que fazer, mas posso dizer o que farei. Caramba, eu sou apenas um estranho como o resto, eu não _sei_ de nada :) Eu acho que os standups e programas do on.net são uma ótima fonte de informação, especialmente dicas iniciais do que está por vir, então certamente vou assistir Essa. se eles disserem que uma postagem no blog está chegando, vou pelo menos lhes dar o benefício da dúvida e ver o que eles têm a dizer. Mas provavelmente vou deixar comentários / fazer perguntas sobre ambos.

No entanto , o último link acima, forneceu alguns bons insights

Há também o repositório de sistema do projeto Roslyn, que provavelmente terá muita ação nos próximos meses

Alguém tem um TL; DR no episódio on.net?

Acho que sou altamente incomum em _hating_ assistindo a vídeos sobre programação. Me mande mensagens a qualquer hora 😄

Inferno sangrento! Até não sou IDE em meus métodos de aprendizagem 😱

Acho que sou muito incomum em odiar assistir vídeos sobre programação. Envie-me uma mensagem a qualquer momento: sorria:

Qual é o problema? É _apenas_ uma hora do seu tempo. :sorriso:

@rhires

Parceiro. Essa é provavelmente uma das melhores postagens que já vi sobre esse assunto nos últimos 3 dias!

Pequeno preço a pagar para permanecer na vanguarda do mercado, mas para cada um deles;)

Tl básico; dr:
A equipe começou a obter feedback de clientes internos como xamarin e externos de que a migração de projetos existentes para project.json era difícil e fazer com que project.json trabalhasse junto com projetos existentes, bem como outras cadeias de ferramentas, como nativas e outras plataformas como o Android significariam trazer uma quantidade significativa de código (ou conceitos) do msbuild. Isso levaria muito tempo e esforço e atrasaria o lançamento por uma quantidade de tempo inaceitável, bem como retardaria o trabalho futuro (incluindo para outros produtos como o xamarin studio e mono Develop, bem como desenvolvedores de plugins do Visual Studio).

Em vez disso, eles optaram por basear o sistema de compilação no msbuild, mas trazer as coisas que as pessoas gostaram do novo sistema. Quanto ao tempo, a aquisição do xamarin não era conhecida mesmo quando o RC1 foi feito, mas agora que foi feito, mudou muitas coisas.

Eles também reconhecem que as pessoas gostam muito de project.json e elas também gostam, e que desejam reter o máximo de vantagens disso, talvez até permitindo que o msbuild leia os arquivos project.json também por meio de um destino. Os cenários sem Cli e VS também são vistos como um cenário central. Eles também falam um pouco sobre outros sistemas de construção e o objetivo é permitir que as pessoas usem outras coisas além do msbuild se quiserem

Em seguida, eles falam um pouco sobre o RC2 e o que está lá dentro e também refletem sobre o que poderiam ter feito de diferente em relação à migração do sistema do projeto, sendo mais aberto antes e tendo mais conversas no GitHub e assim por diante.

Eu recomendo assistir, provavelmente estou perdendo alguns pontos importantes aqui.

@ aL3891 - obrigado pelo ótimo resumo. Foi um trabalho árduo acompanhar o vídeo. Eu concordo que eles devem escrever um resumo do texto. Percebi que eles estão "aprendendo", e ainda incomodados em abrir seu processo, mesmo que digam que é uma coisa boa. Então, esperançosamente, esta será uma boa experiência de aprendizado para eles e veremos as mudanças e seremos os beneficiários delas.

@ aL3891 Obrigado pelo resumo!

Pequeno preço a pagar para permanecer na vanguarda do mercado, mas para cada um deles;)

Ah, mas eu não estou no limite do sangramento , fico um pouco para trás a partir daí. Bem longe o suficiente para não me cortar, ou pelo menos foi o que pensei quando adotei o .NET Core pós-RC1 😢

@shederman dado que "pós-RC1" é basicamente nightlies ou fonte, exatamente como você gosta de seu bife?

@neoKushan Eu quis dizer que apenas "adotamos * o .NET Core _após_ o lançamento do RC1. Ainda estamos no vanilla RC1.

Por isso, gostamos do nosso bife mal passado. Mas acabamos de cortar um pedaço realmente cru e estamos gritando para o garçom.

Mas está tudo bem, parei de chamar o garçom e agora chamei o maitre'd (nosso representante de parceiro do Grupo Microsoft) para vir me ver e discutirmos a tomada de decisões, a disseminação de informações e o direcionamento da plataforma.

Não sabemos nada!

Não recebemos informações suficientes, muita teoria e conjecturas sobre este assunto. Resumo rápido para os preguiçosos que não querem ler este tópico:

O que nós sabemos

1. xproj será convertido em csproj.
2. Nós 'podemos' ter um arquivo nuget.json.
3. Estamos usando msbuild .
4. Tudo isso acontecerá em etapas.
5. As bibliotecas não mudarão.
6. Você não terá que especificar todos os arquivos em csproj.

O que ainda não sabemos

1. O csproj compilará para .nupkg?
2. O csproj compilará para várias arquiteturas e destinos de uma vez x86 / x64 dotnet / dotnetcore?
3. Haverá um arquivo nuget.config separado.
4. Como os comandos serão tratados para executar npm / gulp / bower / etc.?
5. Poderemos usar dotnet build assim como msbuild ? Estou totalmente pronto para o 'único .net' que @shanselman aspira.
6. As referências do intellisense para projetos permanecerão ou desaparecerão?
7. O conjunto de ferramentas ou linha de comando do VS será bom o suficiente para que nunca tenhamos que editar o csproj?
8. Receberemos ferramentas de dotnet add reference MyAssembly ?

Acho que esse problema deve ser encerrado até termos mais informações.

Estou totalmente pronto para o 'único .net' que @shanselman aspira.

Este aqui ? : smile:: +1:: +1:: +1:

Acho que esse problema deve ser encerrado até termos mais informações.

mas mas mas ... então o que farei da minha vida ??? : cry:: sorriso:

@RehanSaeed

E se eu tiver problemas com a lista "O que sabemos"?

Devo esperar por clareza na lista "O que ainda não sabemos" antes de levantar minhas preocupações?

Ou devo apenas calar a boca e engolir isso?

Como bem sei, muitas pessoas gostariam ... 😉

De tudo o que tenho visto, a decisão é 100%, imutável em:

Então, o que mais eu preciso de "O que ainda não sabemos"?

@shederman Você realmente pode querer assistir ao vídeo On.Net. Isso dá um monte de raciocínio por trás da decisão.

Fyi: Eu geralmente altero a velocidade para 1,5 para assistir mais rápido. https://www.youtube.com/watch?v=N9MteJH-HsQ

Se vamos continuar com um arquivo de projeto baseado em XML, por favor, POR FAVOR, você pode sugerir / encorajar / exigir que as ferramentas coloquem o conteúdo do arquivo em algum tipo de ordem. E "cronológico" NÃO é uma ordem aceitável. A maior dificuldade que encontrei com os arquivos proj é a dificuldade de mesclá-los. Apenas coloque-os em ordem alfabética, pelo menos. Sim, ainda teremos o problema de mesclagem ocasional, mas vou considerar "ocasional" em vez de "onipresente" a qualquer dia.

@MelGrubb a única coisa que sabemos é que o novo layout do projeto NÃO listará todos os arquivos presentes, será exatamente como o project.json faz

Para qualquer coisa que deva ser gerenciada manualmente, TOML, por favor.

JSON não faz sentido algum para configuração. Faz ainda menos sentido do que XML.

Para qualquer pessoa interessada, parece que os bits RC2 estão disponíveis (nenhuma postagem de blog que eu possa ver)

https://www.microsoft.com/net/core#windows

e https://www.microsoft.com/net/download#core

Meus dois centavos, fwiw:

Adorei a simplicidade do project.json. Aqui está o que eu gostaria (e não gostaria) de ver nas ferramentas baseadas em MSBuild:

• O MSBuild não deve ser vinculado ao VS ou a qualquer outro IDE / editor. Deve ser uma ferramenta autônoma que pode ser instalada por conta própria. (Ou incluído como parte da instalação dotnet cli.) Digo isso porque tive que instalar uma instância completa do VS em agentes de compilação apenas para obter o MSBuild. Isso nunca fez sentido para mim.
• O próprio MSBuild (ou dotnet cli contendo MSBuild) deve ser instalável com uma linha de comando - seja apt-get, chocolately, homebrew, powershell ou bash / curl. Se eu não conseguir instalar isso como parte de uma configuração totalmente automatizada de um agente de compilação (por exemplo, em circle.yml ou Dockerfile), será um obstáculo e uma fonte de dor.
• O MSBuild deve ser muito amigável com a linha de comando. Devo ser capaz de fazer qualquer coisa na linha de comando - e, portanto, ser capaz de automatizar qualquer coisa em um processo de construção - em um circle.yml, bash ou outro arquivo de script. E eu gostaria de ver um bom uso de stdin e stdout, para que eu possa inserir / retirar comandos do MSBuild.
• Trabalhar em um projeto .NET Core no VS Code (ou outro editor não-VS) não deve exigir informações específicas do VS em um arquivo csproj ou em qualquer outro lugar. As informações do projeto, dependências do pacote nuget, destinos da plataforma, diretivas do compilador, etc. devem ser compartilháveis ​​entre os desenvolvedores que usam IDEs / editores diferentes. Isso faz sentido em um arquivo de projeto. Mas as pessoas que não usam o VS não devem ter que ver as configurações das ferramentas do VS - elas devem estar em um arquivo separado.
• O (s) arquivo (s) de projeto precisam ser fáceis de entender e editar manualmente. As ferramentas são fantásticas, mas devo ser capaz de abrir o arquivo e entender o que elas estão fazendo por mim. E faça alterações facilmente.
• Embora eu saiba que não há diferença na funcionalidade / capacidade, tenho uma forte preferência pessoal por json em vez de xml. Eu também acho que usar json ajudará a atrair desenvolvedores de outras pilhas. Já é difícil atrair pessoas para .NET sem fazer uma das primeiras coisas que elas veem um arquivo XML grande e difícil de decifrar. (Isso é mais emocional do que lógico, mas acho que é importante.) Por favor, pelo menos faça json uma opção e use essa opção em geradores yeoman e outros novos modelos de projeto. Na pior das hipóteses, aceite rapidamente a solicitação de pull inevitável que implementa um formato json simples no repositório MSBuild.
• Seria bom manter os "scripts" no estilo npm, para que eu possa compartilhar facilmente os comandos usados ​​para dev, test, debug, build, run, docker build / run, etc. com minha equipe. Eles podem ir em seus próprios arquivos de script, mas fazem sentido (para mim) como parte do arquivo de projeto.

@jtbennett

"Mas as pessoas que não usam o VS não devem ter que ver as configurações das ferramentas do VS - elas devem estar em um arquivo separado."

Só para adicionar, agora há um monte de coisas em outros arquivos que provavelmente devem ser colocados no arquivo msbuild. Coisas ignoradas são um bom exemplo disso, desde que arquivos de projeto ainda sejam suportados. Eu não posso te dizer quantos projetos eu vi que construíram no VS, mas não da linha de comando

@jtbennett

O MSBuild não deve ser vinculado ao VS ou a qualquer outro IDE / editor.

Ele não estará vinculado ao VS de forma alguma, será entregue via Nuget, portanto, não estará vinculado a nada.

O próprio MSBuild (ou dotnet cli contendo MSBuild) deve ser instalável com uma linha de comando

Isso não mudará a partir de hoje, você ainda será capaz de instalar o dotnet cli através das fontes de pacotes usuais.

O MSBuild deve ser muito amigável com a linha de comando.

_MSBuild_ será efetivamente parte da construção em si, então não acho que você precisará passar opções de linha de comando. No entanto, donet (CLI) obviamente será amigável na linha de comando e acho que isso é tudo que você deseja / precisa.

Trabalhar em um projeto .NET Core no VS Code (ou outro editor não-VS) não deve exigir informações específicas do VS em um arquivo csproj ou em qualquer outro lugar.

Concordo plenamente com isso. Esperando que o "novo" formato do projeto seja muito mais simplificado.

O (s) arquivo (s) de projeto precisam ser fáceis de entender e editar manualmente.

Eles disseram que isso também é uma prioridade para eles.

Embora eu saiba que não há diferença na funcionalidade / capacidade, tenho uma forte preferência pessoal por json em vez de xml. Eu também acho que usar json ajudará a atrair desenvolvedores de outras pilhas. Já é difícil atrair pessoas para .NET sem fazer uma das primeiras coisas que elas veem um arquivo XML grande e difícil de decifrar.

Acho isso interessante, pessoalmente acho que XML é muito mais fácil de decifrar do que JSON, mas acho que muito disso se resume ao quão bem projetado é o esquema (para ambos). Tive que decifrar alguns XML horríveis no passado com nomes de elementos realmente horríveis (como "Elemento") e, embora o MSBuild não seja de forma alguma o pior infrator nesse aspecto, certamente deixa muito a desejar. Com JSON, o nome da chave pode sofrer os mesmos problemas.

Curiosamente, recentemente tive que trabalhar em um projeto em que alguém tentou incorporar JSON em elementos XML :(

Postagem do blog RC2 agora disponível: https://blogs.msdn.microsoft.com/webdev/2016/05/16/announcing-asp-net-core-rc2/

A postagem principal do .net também está ativa https://blogs.msdn.microsoft.com/dotnet/2016/05/16/announcing-net-core-rc2/

Obrigado @neoKushan !

@michaelvolz Não creio que esse arquivo vá permanecer, se assim for: https://github.com/dotnet/cli/blob/rel/1.0.0/Documentation/specs/runtime-configuration-file .md

System.GC.Server (antigo: gcServer) - Booleano que indica se o servidor GC deve ser usado (Padrão: verdadeiro).

e

Poderíamos usar um formato diferente para o arquivo deps, mas se já estivermos integrando um analisador JSON ao host, parece mais apropriado reutilizá-lo aqui.

Parece um pouco estranho para eles terem XML para a _configuração do projeto_, mas .json para a _configuração do tempo de execução_?

Parece um pouco estranho para eles terem XML para o projeto, mas .json para o tempo de execução?

Agora? :rindo:

@ Mike-EEE Bom ponto! Eu atualizei para esclarecer o que eu quis dizer: beijar:

@neoKushan não, você estava certo da primeira vez. : smile: Eu estava concordando com você do meu jeito sarcástico e quase contraproducente. : smirk_cat:

Mas sim ... 100% de acordo que ter formatos diferentes dentro de uma solução é enlouquecedor. Ter um único formato em toda a linha reduz a complexidade, a troca de contexto e, portanto, a _confusão_. É um dos motivos pelos quais desejo ver o MSBuild habilitar formatos diferentes e se tornar agnóstico em relação a formatos . Opa, aviso, plug desavergonhado. :sorriso:

Acho que serei um seguidor de sua cruzada sagrada @ Mike-EEE, já que estamos presos ao msbuild, vamos torná-lo melhor.

Ei, obrigado @sandorfr ... sinta-se à vontade para contribuir com o tópico (mesmo que seja uma reação /: + 1 :). Estou me sentindo um pouco sozinho lá e definitivamente entrando em um território disputado! Do meu ponto de vista, eu estaria muito aberto para melhorar meu produto para aumentar a adoção / favorabilidade / usabilidade / simpatia se houvesse uma grande quantidade de clientes forçados a usar meu produto por qualquer motivo. Mas eu não estou no comando, então. : stick_out_tongue:

@ Mike-EEE Eu li um pouco do tópico, estou tão deprimido agora ... Você entrou no mundo legado de mentes legadas: D.

Vamos torcer para que o pessoal da Microsoft esteja mais aberto às suas ideias, porque na verdade estou bem com o msbuild apenas se a coisa for feita de forma mais simples e direta e eu não precisar de um Gui para editar meu projeto (sim json intellisense foi muito melhor do que as guias usuais de projeto do Visual Studio).

Você entrou no mundo legado das mentes legadas: D.

Wellllll-disse @sandorfr ... wellllll-disse.

Para quem não sabe do standup, acesse: https://live.asp.net/

OK, eu sou um preguiçoso total e finalmente verifiquei isso agora. Parece que a próxima luta é na semana que vem? A equipe está pulando esta semana?

@ Mike-EEE Interessante, definitivamente estava agendado para hoje à noite em um ponto, mas eu me pergunto se mudou. Eu twittei @shanselman , espero que seja apenas um engano, mas como o RC2 foi lançado ontem, eles podem querer pulá-lo esta semana.

Ok legal @neoKushan ... apenas me certificando de que a sanidade está fixada na minha cabeça pelo menos uma vez. Para ter certeza, eu também não gostaria de ser tão rápido em lidar com todas as nossas perguntas e descontentamento. :piscar:

do Slack:

jongalloway [9:31] Tenho certeza de que o ASP.NET Community Standup amanhã foi cancelado - tanto o shanselman quanto o damianedwards estão na OSCON.
...
davidfowl [9:34] damianedwards: está de volta ... mas o shanselman está em oscon
...
jongalloway [9:46] Sim, ASP.NET Community Standup foi definitivamente cancelado para 17/05. Eu atualizei o site.

@ Mike-EEE lidando com todo o nosso ... descontentamento

😆

Caso ainda restasse alguma dúvida: https://twitter.com/shanselman/status/732585321775267842

tem que pular. Estou em #vslive e OSCON

Há uma coisa que gosto muito de project.json: todos os arquivos são incluídos por padrão no projeto, sem a necessidade de incluir explicitamente cada um deles. Com projetos grandes (quero dizer, milhares de arquivos), o processo de mesclagem era realmente doloroso por causa do XML, mas também por causa de cada arquivo listado no csproj.

Sabemos se vai haver alguma melhora deste lado?

@pierrus Foi mencionado que eles não querem voltar aos dias em que todos os arquivos estavam listados dentro do csproj.

@MaximRouiller OK não sabia disso, ótimo!

@MaximRouiller mas eles querem voltar para os dias em que MSBuild era o Um Anel ™, quero dizer Desenvolver Tool. 😉

_Ash nudertog vegal durbatulûk, ash nudertog vegal gimbatul,
ash nudertog vegal thrakatulûk agh burzum-ishi krimpatul._

@shederman Eu

Meu pensamento é que inicialmente eles queriam enviar o formato project.json , mas normalizar o modelo com csproj / Xamarin apenas exigiria que eles implementassem o framework por mais tempo. O ganho mais rápido foi voltar ao csproj. Eles poderiam manter a nova forma em um arquivo separado enquanto mantinham os puros "dados apenas" dentro do csproj. Isso para mim explica o trabalho massivo do RC2 que foi feito.

Se você mover propriedades que quase não mudam e manter os novos recursos interessantes em um arquivo separado? Nós realmente não perdemos nada. Sim, vamos voltar ao monstro ... mas não estamos muito longe.

Eu não tenho nenhum conhecimento interno sobre isso. Isso é pura especulação da minha parte.

Enfim ... não estamos mais terminando em um ciclo de lançamento anual. Se eles estiverem prontos para a transição de project.json para csproj pós-RTM, estou assumindo que mudanças maiores também podem ser lançadas após o RTM.

Alterações das quais ninguém, exceto a equipe MS, está ciente.

@MaximRouiller Não consigo resolver as "possíveis" mudanças que _podem_ estar ocorrendo.

Acabei de trabalhar com as mudanças anunciadas , que estão saindo da construção leve, para usar o MSBuild e o xproj para tudo.

Sim, vamos voltar ao monstro ... mas não estamos muito longe.

Hum, se nós _descolamos_ algo que está funcionando para 90% dos casos de uso para mover _back_ para algo que é excessivamente complicado para esses casos de uso, bem, eu tenho apenas uma pergunta:

Por quê?

Por que dotnet build chamando o MSBuild quando msbuild já faz isso muito bem. Por que desaprovar a construção simples? Por que fazer um trabalho

algo que está funcionando para 90% dos casos de uso

[citação necessária]

Mesmo supondo que sejam 90% dos casos de uso, você trabalharia com qualquer coisa que falhasse 1/10 das vezes?

volte para algo que é excessivamente complicado

Novamente, [carece de fontes?], A única coisa que sabemos até agora é que será o XML-csproj e que não conterá a lista de arquivos. Não sabemos mais nada sobre como o sistema funcionará e não estou convencido de que precisamos saber, porque todos aqui estão apenas chamando "dotnet build" e independentemente de como a compilação é realizada, isso não mudará.

Por que o dotnet build está chamando o MSBuild quando o msbuild já faz isso muito bem.

Deixamos de dizer que o MSBuild é "excessivamente complicado" para "O MSbuild já faz isso muito bem"? Atualmente, dotnet build apenas _parece_ simples porque tudo o que acontece em segundo plano está oculto para você. Mudar para o MSbuild não muda isso, no que diz respeito a você, ainda é apenas dotnet build .

Para alguém que insiste em dizer que precisa haver uma distinção entre o sistema de projeto e o sistema de compilação, você não está disposto a aceitar que há, de fato, uma diferença entre ter arquivos MSBuild XML como sistema de projeto e ter MSBuild como sistema de compilação - aí já é uma separação.

trabalhando para 90% dos casos de uso

@shederman Por favor, pare de presumir que tudo é ASP.NET ... Você sai como _desprecisamente ignorante_ neste tópico. Eu sugiro que você se acalme por enquanto até que realmente obtenhamos mais informações sobre o novo sistema de projeto, em vez de apenas presumir que tudo está condenado.

@shederman O motivo pelo qual você constrói um calço sobre algo é quando deseja substituí-lo. Abstraia-o para que você possa alterar a implementação. Nós fazemos isso todo dia. É chamado de refatoração.

Espero que seja substituído. Além do XML, acho que também é lento em comparação com outras coisas, se bem me lembro.

Se for como dotnet build a questão é - quão difícil será alterar o processo de construção do sublinhado? É possível substituir o msbuild por algo diferente? Quantas fitas de duto serão necessárias?

Se pudéssemos fazer essa mudança em 1 ou 2 meadas de fita adesiva, bem, é aceitável.

@neoKushan Deixamos de dizer que MSBuild é "excessivamente complicado" para "MSbuild já faz isso muito bem"?

Hum, não. Eu acredito que estava dizendo que o comando msbuild executa o MSBuild muito bem. Eu não estava julgando o MSBuild como ferramenta. Não ficou claro?

@neoKushan Mesmo supondo que sejam 90% dos casos de uso, você trabalharia com qualquer coisa que falhasse 1/10 das vezes?

Ninguém está dizendo nada sobre nada que está falhando . Algumas ferramentas são mais adequadas para algumas finalidades do que outras. Eu diria que o poder e a complexidade do MSBuild são adequados para a finalidade em cerca de 10% das compilações. Podemos discutir sobre as porcentagens exatas, mas é definitivamente menor que 100%.

@neoKushan Mudar para MSbuild não muda isso

Hum, isso não muda o processo de construção

@neoKushan, você não está disposto a aceitar que existe de fato uma diferença entre ter arquivos MSBuild XML como sistema de projeto e MSBuild como sistema de compilação - já existe uma separação.

Desculpe, mas não vejo como ter uma ferramenta para fazer duas coisas é uma separação.

@poke Por favor, pare de presumir que tudo é ASP.NET

Eu não sou. Estou dizendo que a solução proposta não funciona bem para compilações simples. Alguns dos quais são compilações ASP.NET. Pessoalmente, também não vejo por que preciso de algo tão poderoso quanto o MSBuild para um aplicativo de console simples.

@poke Você

Espero que sim. Porque o que desconheço propositalmente são os maravilhosos benefícios que os usuários do MSBuild proporcionam.

@poke , sugiro que você se acalme por enquanto, até que realmente tenhamos mais informações sobre o novo sistema de projeto, em vez de apenas presumir que tudo está condenado.

Cara, estou tranquilo, prometo.

Eu apenas não estou permitindo que pontos de vista dos quais discordo fiquem incontestáveis. Prometo que não é sinal de agitação. Amor de Deus, eu nem sequer ficar agitado por alguns pouco twerp _person_ me chamando de ignorante 😉

Que é meio irônico quando este pequeno twerp selfsame _person_ está chamando para me acalmar.

Engraçado mesmo.

@MaximRouiller @shederman O motivo pelo qual você constrói um calço sobre algo é quando deseja substituí-lo. Abstraia-o para que você possa alterar a implementação

Ah, sim, e esse seria um bom motivo para fazer isso, exceto pelo que ouvi, não há intenção de substituir o MSBuild. É o sistema de compilação selecionado para um futuro previsível. Gostaria que permitíssemos que os projetos permanecessem sem itens específicos do MSBuild e que dotnet build fizesse a compilação leve existente ou selecionasse uma ferramenta de compilação baseada em algo, por exemplo, config. Se você quiser usar o MSBuild, crie um arquivo msbuild e execute msbuild .

Hum, não. Eu acredito que estava dizendo que o comando msbuild executa o MSBuild muito bem.

Para colocar isso em contexto:

Por que o dotnet build está chamando o MSBuild

dotnet build faz muito mais do que "apenas" chamar o compilador, dê uma olhada na implementação CLI atual da compilação dotnet . Construir um projeto é apenas parte do processo dotnet build . Eventualmente _parte_ desse processo será chamar msbuild mas esse não é o seu trabalho, é o trabalho do CLI.

Eu não estava julgando o MSBuild como ferramenta.

Tudo o que você fez neste tópico foi julgar o MSBuild como uma ferramenta. Afirmar que você não está fazendo tal coisa é, francamente, ridículo.

Não ficou claro?

Muito pouco do que você diz é claro, ou pelo menos bem pensado.

Ninguém está dizendo nada sobre nada que está falhando. Algumas ferramentas são mais adequadas para algumas finalidades do que outras.

Portanto, algumas ferramentas falham em ser adequadas para o propósito.

Eu diria que o poder e a complexidade do MSBuild são adequados para a finalidade em cerca de 10% das compilações.

Bem, isso é interessante porque todos os desenvolvedores de .net do Visual Studio por aí teriam que discordar. Você está efetivamente dizendo que o MSBuild não é bom para 90% dos usuários (ignorando o fato de que você está arrancando figuras da sua bunda), o que é - novamente - ridículo.

Hum, isso não muda o processo de construção, não.

Se o processo não for alterado, então seu único argumento é que você não gosta da estrutura do projeto - o fato de ser um MSbuild ou o que quer que esteja por trás do capô é, portanto, completamente irrelevante .

No entanto, ele muda o que é necessário para o processo de construção funcionar (ou seja, arquivo csproj)

Essa é literalmente a única coisa que está realmente mudando, tanto quanto as pessoas verão.

e a velocidade com que é executado.

[citação necessária]

Por favor, mostre-me como o novo processo é mais rápido ou mais lento, visto que atualmente não existe .

Desculpe, mas não vejo como ter uma ferramenta para fazer duas coisas é uma separação.

Como uma ferramenta não faz duas coisas, o MSBuild pode ser o sistema de construção, mas a mudança tem a ver com o sistema do projeto. Não há absolutamente nada que o impeça de usar um sistema de compilação diferente, se quiser, não é nada trivial.

Eu não sou. Estou dizendo que a solução proposta não funciona bem para compilações simples

dotnet new
dotnet restore
dotnet build

Por favor, mostre-me como a solução proposta muda alguma coisa no cenário de "construção simples"

Alguns dos quais são compilações ASP.NET.

yo asp-net web
dotnet restore
dotnet build

Pessoalmente, também não vejo por que preciso de algo tão poderoso quanto o MSBuild para um aplicativo de console simples.

Você não. Você só precisa de dotnet build . Que você ainda terá. Nada muda aí.

Estou calmo, prometo.

pequeno idiota

: -1:

@neoKushan Seria muito bom se você pudesse compreender o conceito entre uma resposta a um trecho citado e um comentário sobre toda a discussão. Presumo que você seja _capaz_ de fazer isso, então a única conclusão é que é deliberado. Em caso afirmativo, apenas para informá-lo de que é uma tática intelectualmente desonesta. Eu esperava que você soubesse disso, mas estou dando o benefício da dúvida aqui.

Eu também acho que você definitivamente deveria tomar uma pílula relaxante. Estamos apenas discutindo o que acreditamos individualmente ser o melhor para o framework, não estamos tentando _lutar_ um com o outro. Ataque o argumento, não a pessoa. Bem, é isso que tenho _tentado_ fazer há alguns dias (exceto em um caso recentemente, veja abaixo).

Bem, isso é interessante porque todos os desenvolvedores de .net do Visual Studio por aí teriam que discordar.

Engraçado, eu coletei evidências que dizem algo diferente. Onde você conseguiu o seu?

Como uma ferramenta não faz duas coisas, o MSBuild pode ser o sistema de construção, mas a mudança tem a ver com o sistema do projeto. Não há absolutamente nada que o impeça de usar um sistema de compilação diferente, se quiser, não é nada trivial .

Sim. Então, nós concordamos. Eu realmente gostaria se fosse trivial.

É realmente um pedido tão irracional? Sério?

Você não. Você só precisa construir dotnet. Que você ainda terá. Nada muda aí.

E dotnet build fará o que exatamente? Desembolsar para msbuild ? Por que não podemos simplesmente usar msbuild se quisermos usar o MSBuild? Qual é exatamente o propósito de dotnet build nessa situação? O que isso adiciona ao ferramental?

pequeno idiota 👎

Uma tentativa de ser engraçado, mas provavelmente você está certo.

@poke Peço desculpas sem reservas.

Seria muito bom se você pudesse compreender o conceito entre uma resposta a um trecho citado e um comentário sobre toda a discussão. Presumo que você seja capaz de fazer isso, então a única conclusão é que é proposital. Em caso afirmativo, apenas para informá-lo de que é uma tática intelectualmente desonesta. Eu esperava que você soubesse disso, mas estou dando o benefício da dúvida aqui.

Literalmente, não tenho ideia do que você está se referindo.

Eu também acho que você definitivamente deveria tomar uma pílula relaxante.

...

Ataque o argumento, não a pessoa.

: InsertRolleyEyeEmoticonHere:

Engraçado, eu coletei evidências que dizem algo diferente. Onde você conseguiu o seu?

Ok legal, então de onde veio o número de 10% / 90%?

Sim. Então, nós concordamos. Eu realmente gostaria se fosse trivial.

O que não tem nada a ver com a mudança para msbuild, você já terá problemas para mudar o sistema de compilação atual de dotnet build .

E a compilação dotnet fará o que exatamente? Desembolsar com o msbuild?

O que é diferente de dotnet build chamar msbuild em vez de dnx ou roslyn?

Por que não podemos apenas usar msbuild se quisermos usar MSBuild?

Então você deseja usar o MSBuild agora? Nada está impedindo você, é um pacote nuget hoje em dia. Enlouquecer. Estou surpreso que você esteja perguntando, dado o quanto você odeia msbuild.

Qual é exatamente o propósito da compilação do dotnet nessa situação? O que isso adiciona ao ferramental?

Estamos realmente discutindo os méritos de dotnet build ? Você não gosta de dotnet build ? Você não entende o propósito de dotnet build ? Isso não parece provável. O que você está tentando perguntar?

@neoKushan, por favor, pare de hostilizá-lo. isso não é construtivo.

Ok legal, então de onde veio o número de 10% / 90%?

Isso veio de minhas experiências pessoais. Descobri que cerca de 90% das compilações que minha equipe e eu criamos nos últimos anos não exigiram nada mais complexo do que o que o RC1 dotnet build faz.

O que não tem nada a ver com a mudança para msbuild, você já terá problemas para mudar o sistema de compilação atual da compilação dotnet.

Por favor, esclareça, não tenho certeza do que você quer dizer aqui.

Então você deseja usar o MSBuild agora? Nada está impedindo você, é um pacote nuget hoje em dia. Enlouquecer. Estou surpreso que você esteja perguntando, dado o quanto você odeia msbuild.

_suspirar_. Minha pergunta é: por que dotnet build deveria pagar para o MSBuild quando msbuild faz isso realmente bem? Por que dois comandos fazem uma coisa?

Já perguntei isso cerca de três vezes até agora, e todas as vezes você entendeu mal ou interpretou mal.

Estou perguntando sobre as ações de dois comandos de linha de comando diferentes
Estou perguntando por que ambos farão a mesma coisa
Estou perguntando, se ambos fazem a mesma coisa, por que não ter um comando
Estou perguntando o que o segundo comando adiciona à situação se ambos fizerem a mesma coisa
Não estou julgando a qualidade das ferramentas subjacentes nesse contexto, embora eu possa ter feito isso em outro lugar
O referido julgamento em outro lugar não tem impacto sobre a pergunta que está sendo feita, uma vez que a pergunta que está sendo feita é sobre os comandos da linha de comando e suas ações, e não sobre as ferramentas subjacentes.
Não estou tentando discutir o que mais essas ferramentas podem ou não ter feito no passado, apenas o que se destinam a fazer no futuro

Desculpe pela longa exposição explicando uma questão de uma frase, mas aparentemente é necessária.

Artigo sobre InfoQ :
"A Microsoft chegou à conclusão de que o experimento project.json falhou e voltará a usar arquivos .csproj." : desapontado:

Como eu disse, a percepção é importante.

Minha pergunta é: por que o dotnet deveria construir um shell para o MSBuild quando o msbuild já faz isso muito bem? Por que dois comandos fazem uma coisa?

Porque eles não fazem apenas uma coisa?

Por que o MSBuild deveria executar shell no csc quando o csc já faz um bom trabalho de construção? Por que dois comandos fazem uma coisa?

Por que dotnet test deveria pagar para o executor de teste xUnit quando ele já faz um bom trabalho em executar testes por conta própria. Por que dois comandos fazem uma coisa?

Por que dotnet restore deveria pagar para o NuGet quando o NuGet já faz um bom trabalho de instalação de pacotes. Por que dois comandos fazem uma coisa?

Você entendeu ... (espero: wink :)

@sandorfr

@neoKushan, por favor, pare de hostilizá-lo. isso não é construtivo.

Não estou hostilizando ninguém deliberadamente, estou desconstruindo ponto por ponto o argumento de @shederman , que é exatamente o que ele quer que as pessoas façam:

Ataque o argumento, não a pessoa.

Embora, neste ponto, eu nem mesmo tenha certeza de qual é o argumento de @shederman , já que parece que de alguma forma passamos de XML sendo ruim, para MSBuild sendo ruim agora dotnet build é ruim.

Vamos em frente.

Isso veio de minhas experiências pessoais.

Esta é a sua "evidência"? Que, lembre-se, você colocou em negrito:

Engraçado, eu coletei evidências que dizem algo diferente. Onde você conseguiu o seu?

E agora é "Experiência pessoal". Isso é o que chamamos de evidência _anedotal_.

Descobri que cerca de 90% das compilações que minha equipe e eu criamos nos últimos anos não exigiram nada mais complexo do que a compilação dotnet RC1 faz.

E o que você espera que o RC2 dotnet build ou o RTM dotnet build ou o pós-RTM dotnet build mudem a esse respeito?

Por favor, esclareça, não tenho certeza do que você quer dizer aqui.

Seu argumento parece ser (e me corrija se eu estiver errado) algo como "Não é trivial fazer com que dotnet build faça algo diferente do que a Microsoft programou para fazer". O que estava ok nos dias do DNX porque todos nós gostávamos do DNX, mas agora a Microsoft quer usar o MSBuild por baixo do capô e você não gosta do MSBuild, você quer a opção de trocar o MSbuild por outra coisa - meu ponto é que este não é nada novo, se você teve algum problema com DNX, então você não poderia mudar isso também, então qualquer que seja o seu "problema" com dotnet build , não é nada novo e, portanto, não acho que seja relevante para a discussão _real_ aqui, que é a estrutura de project.json movendo-se para. csproj

suspirar. Minha pergunta é: por que o dotnet deveria construir um shell para o MSBuild quando o msbuild já faz isso muito bem? Por que dois comandos fazem uma coisa?

@khellang já respondeu isso, então eu particularmente não quero me repetir, mas isso também porque eu já declarei de forma bastante sucinta qual é a diferença (eu odeio me citar, mas eu não acho que você realmente leu isso):

dotnet build faz muito mais do que "apenas" chamar o compilador, dê uma olhada na implementação CLI atual da compilação dotnet . Construir um projeto é apenas parte do processo dotnet build . Eventualmente _parte_ desse processo será chamar msbuild mas esse não é o seu trabalho, é o trabalho do CLI.

Portanto, novamente, pelo menos pela terceira vez: chamar dotnet build não é sinônimo de chamar msbuild . Não é, como você disse, "dois comandos fazendo uma coisa" e nunca foi. Isso nunca esteve dentro do escopo de toda essa discussão, mas de alguma forma você acabou lá.

A discussão real, a que realmente importa, é a estrutura de project.json e como ela deve ser mesclada em .csproj. O sistema de compilação subjacente é amplamente irrelevante se você quiser apenas algo simples, porque você sempre terá apenas dotnet build .

Então, como podemos distinguir entre o que o msbuild faz e o que o dotnet faz agora? Quais são as diferenças em como eles funcionam? Acho que está faltando nessa discussão. Todos provavelmente já sabem, mas acho que colocar isso na mesa pode criar alguma clareza.

@khellang Gosto da maneira como você expressou isso, mas, a partir daí, posso configurar o que dotnet test faz. Posso colocar um executor de teste diferente do de xunit no project.json, e dotnet test invocará esse executor de teste.

Mas, ainda assim, pelo que ouvi sobre as mudanças futuras, não haverá capacidade semelhante com dotnet build . Ele sempre usará o MSBuild para realizar suas compilações. Esse entendimento não está correto?

@neoKushan, não estou hostilizando ninguém deliberadamente, estou desconstruindo ponto a ponto o argumento de @shederman

Bem, pelo menos agora sabemos o que você _ pensa_ que está fazendo. O que você está _na verdade_ fazendo é deturpar, confundir posições, interpretar mal as coisas deliberadamente e, em geral, ser um pouco estúpido. Seu tom é combativo e você está sendo deliberadamente obtuso. Tanto que tive que tentar quebrar as coisas em um pensamento de cada vez. O que, hilariamente, você interpretou erroneamente como uma mudança de posição.

@neoKushan Embora, neste ponto, eu não tenha nem mesmo certeza de qual é o argumento de @shederman , já que parece que de alguma forma deixamos o XML ser ruim, para o MSBuild ser ruim para agora construir dotnet é ruim.

XML é ruim. MSBuild é ruim. Se dotnet build usar apenas MSBuild, também é ruim. Por favor, tente e continue. Não é tão complicado. Se você não estivesse sendo tão obtuso obstinadamente, você teria entendido isso há muito tempo e seria capaz de realmente adicionar informações construtivas.

@neoKushan Esta é a sua "evidência"? Que, lembre-se, você colocou em negrito:

Não, essa foi minha experiência pessoal, não a evidência. Minha evidência é de 281 entrevistados entre 383 que acreditavam que a mudança do .NET Core de volta para o MSBuild é uma má ideia. E os 85 dos entrevistados que acreditaram que o MSBuild está fundamentalmente quebrado. ESSA é a minha evidência. Onde está o seu exatamente?

Você sabe, para fazer backup de sua declaração de que "... _todos os desenvolvedores do Visual Studio .net lá fora teriam que discordar"? [Enfase adicionada]

@neoKushan A discussão real, o que realmente importa é a estrutura de project.json e como isso deve ser mesclado em .csproj

Na verdade, eu concordo com você. MAS o pano de fundo é extremamente importante. O plano que a MS expressou é que o MSBuild seja o centro do universo de construção. Eu não gosto disso, mas vamos em frente. Diante disso, há uma pergunta simples:

"O MSBuild será o principal sistema de compilação do .NET Framework para sempre ?"

Nesse caso, precisamos apenas de um comando msbuild e não precisamos de um comando dotnet build , ele é totalmente supérfluo.

No entanto, se aceitarmos que em algum ponto o MSBuild pode não ser o _One True Build System_, estaremos em um território mais interessante. Então, ter um dotnet build faz sentido. MAS , então, é extremamente importante que tenhamos esse futuro em mente ao discutir a fusão de csproj e project.json.

O que tenho tentado (talvez mal) apontar é que uma opção melhor (em minha mente) seria tentar manter uma separação clara entre os arquivos de _definição de projeto_ e os arquivos de _definição de construção_. Isso nos configuraria melhor para dotnet build que pode oferecer suporte a vários motores de compilação. Se, em vez disso, movermos tudo para csproj, estaremos nos trancando em um mundo MSBuild.

E sim, eu entendo que essa situação de "apenas uma compilação verdadeira" existia no DNX. Mas eu não questionei isso porque eu gostei da construção que tínhamos. Ah, as situações em que nos colocamos quando aceitamos alegremente as injustiças de que gostamos.

Portanto, considere uma situação em que dotnet build pode usar uma das várias ferramentas de compilação, dependendo da configuração. Assim como dotnet test pode usar um dos vários executores de teste. Agora, dado um mundo tão imaginário, agora como é que você mesclar csproj e project.json? Essa é a discussão que eu quero ter.

@rhires De um nível muito alto dotnet build :

1. Coleta os arquivos do projeto
2. Determina se as condições prévias são atendidas para uma compilação incremental
3. Lê o project.json
4. Determina as estruturas de destino
5. Para cada projeto:
   
   
   
   1. Dependências do Build
   
   
   2. Se incremental, verifica se uma reconstrução é necessária
   
   
   3. Determina diretórios de saída
   
   
   4. Coleta os arquivos de origem
   
   
   5. Determina as opções de compilação
   
   
   6. Executa scripts de pré-compilação
   
   
   7. Executa o compilador com os arquivos de origem e opções
   
   
   8. Executa os scripts de pós-compilação
   
   
   9. Saída de relatórios
   
   

@shederman Obrigado! A partir deste ponto, o que o msbuild adicionaria / subtrairia / substituiria para / de / neste processo?

Bem, pelo menos agora sabemos o que você pensa que está fazendo. O que você está de fato fazendo é deturpar, confundir posições, interpretar mal as coisas deliberadamente e, em geral, ser um pouco estúpido. Seu tom é combativo e você está sendo deliberadamente obtuso. Tanto que tive que tentar quebrar as coisas em um pensamento de cada vez. O que, hilariamente, você interpretou erroneamente como uma mudança de posição.

Pote -> Chaleira

Você mudou de posição tantas vezes que nem consegue se manter, você discutiu literalmente sobre cada aspecto da cadeia de construção, demonstrando que claramente não tem um entendimento tão bom de como todas as peças Juntos como vocês _pensam_ que fazem, ainda _Eu_ estou sendo o idiota porque me atrevo a apontar onde seus argumentos caem no chão. Ainda estou esperando você responder a metade dos pontos que levantei acima, mas tudo o que você faz é seguir em frente e escolher algum outro aspecto do processo de construção.

XML é ruim. MSBuild é ruim. Se dotnet build só usa MSBuild, também é ruim.

Ninguém além de _você_ reivindicou algo assim. Ninguém. Não há o menor indício de que algo desse tipo vai acontecer. Eu disse a você repetidamente que dotnet build não _apenas_ vai chamar MSBuild , eu disse a você que dotnet build e msbuild não são completamente sinônimos de uns aos outros e que dotnet build faz muito mais do que chamar o compilador. Eu até vinculei você ao maldito código-fonte e outros vieram e disseram a mesma coisa, mas você ainda está insistindo que isso é de alguma forma o que está acontecendo?

Por favor, tente e continue.

Que tal _você_ acompanhar? Por favor, mostre-nos de onde você tirou essa ideia de que dotnet build só chamará msbuild . Quem te disse isso? Onde você leu isso?

Minha evidência é de 281 entrevistados entre 383 que acreditavam que a mudança do .NET Core de volta para o MSBuild é uma má ideia. E os 85 dos entrevistados que acreditaram que o MSBuild está fundamentalmente quebrado. ESSA é a minha evidência. Onde está o seu exatamente?

E você tirou 10% desses números, não é? Lembre-se, esta é a sua reivindicação:

Eu diria que o poder e a complexidade do MSBuild são adequados para a finalidade em cerca de 10% das compilações.

Mais tarde, você disse:

Engraçado, eu coletei evidências que dizem algo diferente.

Então, onde está essa evidência? Eu adoraria saber como você tirou essa figura de sua "evidência".

Você sabe, para fazer backup de sua declaração de que "... cada desenvolvedor Visual Studio .net lá fora teria que discordar"?

Fácil: https://msdn.microsoft.com/en-us/library/ms171468.aspx

O Visual Studio hospeda o MSBuild para carregar e construir projetos gerenciados.

Se você usar o Visual Studio para construir seus projetos, use o MSBuild. Mesmo ao trabalhar com o núcleo .net hoje, mesmo com o RC1 VS usei o MSbuild sob o capô. Você pode não gostar do MSbuild, mas, como eu disse, quase todo desenvolvedor de VS usa-o quer percebam ou não.

O plano que a MS expressou é que o MSBuild seja o centro do universo de construção.

Eu não concordo com isso. Eles nunca disseram que seria o centro, tudo o que disseram é que algumas partes de project.json acabariam voltando para .csproj - além disso, eles não disseram uma palavra sobre até que ponto isso muda o dotnet build processo.

"O MSBuild será o principal sistema de compilação do .NET Framework para sempre?"

Nesse caso, precisamos apenas de um comando msbuild, e não precisamos de um comando dotnet build, é totalmente supérfluo.

Como já foi dito várias vezes, dotnet build e msbuild são duas coisas completamente distintas. dotnet build faz mais do que apenas chamar o conjunto de ferramentas do compilador. O objetivo da compilação dotnet é manter o processo de compilação simples para as pessoas. Ver de novo:

dotnet new
dotnet restore
dotnet build

Mesmo que o msbuild se torne um componente central da CLI do dotnet, isso não muda o fato de que o build do dotnet é o invólucro limpo e simples em torno do que é (e sempre será) um sistema bastante complexo. Inferno, metade da razão pela qual a CLI do dotnet existe (e o DNX antes dela) é especificamente para fugir do inferno do argumento de linha de comando que o MSBuild é. Seu argumento é um pouco como dizer "Por que precisamos de um comando npm install quando posso apenas curl o pacote?". Claro, você pode fazer tudo manualmente se realmente quiser, mas não ganha quase nada com isso. E daí se dotnet build usar msbuild sob o capô? Você quase certamente nunca verá ou precisará saber sobre isso.

Você não pode comparar sua experiência anterior com o MSBuild, é totalmente diferente. Todos nós (aparentemente) fomos queimados por isso porque estamos acostumados a abrir o VS, criar um projeto e tê-lo apenas compilado, mas então quando você vai ter esse mesmo projeto compilado em um servidor de compilação, de repente está reclamando de merda isso deve _apenas funcionar_. Provavelmente, uma das melhores coisas que a Microsoft fez com o TFS 2015 foi criar uma definição de compilação que se conecta ao _Visual Studio_ em vez de _MSBuild_ porque você está de volta "apenas funcionando". Isso é exatamente o que este conjunto de ferramentas de construção é - dotnet build não se destina a substituir todo o seu sistema de construção, ele se preocupa apenas com a construção de seus projetos, mesmo que use MSBuild sob o capô. Se você quiser usar algo como TeamCity ou Jenkins, dotnet build é tudo que você precisa dizer a eles para chamarem e dotnet faz o resto. _Como_ isso não é da sua conta.

A única coisa - e eu quero dizer isso completamente, a única coisa que realmente muda para você é o arquivo project.json / csproj. É isso_. É por isso que toda essa discussão sobre o que dotnet build realmente faz e para que MSBuild é bom e ruim é absolutamente _não há sentido_.

@neoKushan pare ...

@neoKushan pare ...

Parte de mim gosta de imaginar a equipe ASP.NET cancelando deliberadamente o standup porque estava gostando do show, e fornecer respostas encerraria tudo. :sorriso:

Da minha posição agnóstica (agora firmemente), ambos os lados parecem ser obstinadamente obtusos em relação aos pontos do outro há algum tempo. Você está conseguindo definir minha imagem mental da comunidade .NET Core como não construtiva e pior. Fale sobre percepção ...

A maioria das coisas que não são do NuGet serão mescladas com o csproj. O que acontecerá com as coisas do NuGet se não houver project.json (nuget.json?)?

fornece uma maneira para que os usuários gerenciem suas dependências da maneira que quiserem e talvez forneça dotnet nuget por padrão, já que o NuGet está bem estabelecido na comunidade .net.

mas não acople todas as coisas do núcleo do dotnet a essa única maneira de gerenciar dependências ( dotnet restore não deve ser igual a dotnet nuget restore ), para muitas pessoas nuget é apenas um repositório de pacotes, mas não um gerenciador de dependências, as pessoas têm outras opções que podem considerar mais produtivas / adequadas para o caso de uso de "gerenciador de dependências".

Manteremos o IntelliSense para gerenciamento de dependências? Este é basicamente um dos melhores recursos de demonstração que temos para project.json.

você pode redirecionar a lógica, não vejo isso como grande coisa, por exemplo, eu vou no nuget.org e faço uma pesquisa por um pacote e copio o id do url, é eficiente.

Você pode querer fornecer também o preenchimento de shell, o que lhe dará muita admiração de pessoas que usam bash ou zsh :

dotnet nuget add S[tab] fornece lista de conclusão para identificadores de projeto começando com S

ter o intellisense nos arquivos proj msbuild * deve ser possível também se você quiser assar uma tag <NuGet> lá, mas mesmo assim, não acople fortemente o nuget a todo o ecossistema, ou seja, <Package>NuGetPackageId</Package> shouldn ' t equivale a <NuGet>NuGetPackageId</NuGet> OU deve haver uma maneira muito simples (e extremamente bem documentada e suportada) de sobrescrever isso.

O plugin do Paket Visual Studio tem autocompletar no nuget, ele funciona, mas é meio lento de qualquer maneira, porque eu presumo que leve algum tempo para retornar a resposta do nuget.org.

Estamos mantendo o formato JSON para gerenciamento de dependências? XML é horrível para esse tipo de coisa (veja Maven). JSON é muito mais simples de representar essas dependências.

Se você está procurando ideias de formato, pode olhar para paket.dependencies , caso contrário, não acho que isso importe muito, editar o project.json foi quase tão bom quanto editar packages.config em termos de lidar com o NuGet, faça o que for conveniente para os usuários que escolhem o NuGet como um gerenciador de dependência de pacote (o que não é 100% dos usuários e não precisa)

Como uma observação lateral, se você ainda precisa de um arquivo lock , você poderia torná-lo legível para o usuário, algo que seja verificado no repositório e fácil de fazer diff?

@rhires A partir deste ponto, o que o msbuild adicionaria / subtrairia / substituiria para / de / neste processo?

Bem, isso depende de como eles o integram. Se eles fizerem um "hard lock", integrando msbuild profundamente na compilação dotnet, que as informações públicas parecem indicar que é sua abordagem preferida, então ele seria substituído por completo pelo msbuild.

No entanto, se eles tornarem dotnet build configurável, espero que funcione algo como:

1. Coleta os arquivos do projeto
2. Lê o project.json
3. Determina as estruturas de destino
4. Determine a ferramenta de construção a ser usada
5. Shell out para a ferramenta de construção
6. Saída de relatórios

@neoKushan É por isso que toda essa discussão sobre o que o dotnet build realmente faz e para que o MSBuild é bom e ruim é absolutamente inútil.

👍

O que eu quero _discussar_ é a aparência de project.json e csproj em um mundo onde dotnet build pode enviar para o MSBuild como uma das _muitas ferramentas de construção possíveis_. Tudo bem? Podemos falar sobre o que estaria em project.json vs o que estaria em csproj, considerando isso?

Porque se _podemos_ discutir isso, acredito que este tópico pode se tornar construtivo.

@jmm Você está conseguindo definir minha imagem mental da comunidade .NET Core como não construtiva e pior

Desculpe por isso. No entanto, se você tiver tempo, sugiro ler alguns dos arquivos de bate-papo de alguns outros grandes projetos de código aberto.

As discussões são, na verdade, um sinal de uma comunidade saudável, assim como na vida. Quando todos seguem um conjunto de líderes cegamente, bem, as coisas normalmente não são tão boas. As decisões, evidências e tomada de decisão devem ser abertas ao interrogatório.

@shederman No interesse de continuar uma discussão produtiva, eu também gostaria de traçar uma linha para discutir as implicações das mudanças propostas.

Acho que a discussão central aqui deve ser sobre o layout e o formato do "novo" .csproj e o que acontece com o project.json (ou, para ser mais específico, a estrutura do "projeto" como um todo). Não acho que o sistema de compilação, seja msbuild ou não, como funciona a compilação dotnet, etc., esteja dentro do escopo _este_ problema. Isso não quer dizer que as discussões sobre isso sejam indesejadas ou inválidas, apenas que não pertencem a este problema _específico_, ao invés disso, devem ser questões distintas. Como qualquer desenvolvedor experiente pode atestar, é muito frustrante quando um relatório de bug contém vários bugs separados e geralmente a primeira coisa que você faz é dividi-los em vários problemas para rastrear - acho que é isso que está faltando aqui.

Da minha perspectiva _pessoal_, não me importo com o que o sistema de compilação é ou como funciona. Não quero dizer que soe ignorante ou desdenhoso para aqueles que o fazem, quero dizer que, da perspectiva do desenvolvedor, só quero saber se o "dotnet build" expulsa minha montagem, desde que a estrutura do projeto esteja correta - até o ponto quanto a mim, dotnet build -> Projeto ->-> Montagem. A única coisa que realmente importa para mim, e qual deve ser o escopo desta discussão (e acho que finalmente estamos de acordo aqui), é como esse projeto se parece e o que ele significa para o meu fluxo de trabalho diário.

Não quero lidar com o inferno de merge apenas porque adicionei um arquivo .cs, nem quero lidar com um arquivo XML de mil linhas apenas porque algum sistema que _Eu não me importo_ depende disso - eu não Acho que qualquer um de nós sabe e isso tem sido um problema para o desenvolvimento do VS há anos. Tivemos um vislumbre de esperança com o formato project.json como está hoje porque era _tão muito melhor_ do que o que veio antes, então eu entendo completamente e entendo por que os ânimos se desgastaram tão rapidamente com a mera sugestão de que estaríamos voltando para os "maus velhos tempos", mas ao mesmo tempo vale a pena dizer que não devemos nos enganar - o project.json hoje não é de forma alguma _perfeito_, ele tem seu próprio conjunto de problemas e embora eles possam ser menores em comparação com o questões do "antigo" csproj, vale a pena ser objetivo e discutir onde as coisas poderiam ser melhoradas e o que poderia ser melhor.

Definitivamente, há uma possibilidade _melhor dos dois mundos_.

Acho que a discussão central aqui deve ser sobre o layout e o formato do "novo" .csproj e o que acontece com o project.json (ou, para ser mais específico, a estrutura do "projeto" como um todo).

Você sabe, isso foi mencionado algumas vezes neste tópico, mas pensei em mencioná-lo novamente, apenas para compartilhar meu "aha pessoal" esta manhã, mas há todo um outro esforço em andamento com o Sistema de Projetos baseado em Roslyn - ou para ser mais preciso em seu leia - Sistema Central de Projetos (CPS) . Navegar por sua documentação parece ser mais um esforço de definição de projeto do que um processo. Talvez seja aqui que toda a magia entre .json e .csproj está sendo consolidada? E então o MSBuild será relegado como um ponto de extremidade do processo? _Isso_ não seria bom. :sorriso:

De qualquer forma, eu comecei / assisti aquele repositório para começar a receber atualizações sobre o que está acontecendo lá. : +1:

(Eu também estou meio que me perguntando se devemos mover esta discussão para um novo problema lá.)

@neoKushan Definitivamente, o fato de haver msbuild envolvida não é problemático por si só. E eu acho que há um caminho a seguir que nos permitiria manter formatos de arquivo simples legíveis / editáveis ​​por humanos enquanto aproveitamos o poder do msbuild.

O que me preocupa são argumentos como "msbuild foi testado em batalha", msbuild regular é, mas o xplat atual não parece ser. Quando olhamos para os problemas do repositório github relacionado, ainda não chegamos lá. Além disso, a equipe do msbuild já disse que o suporte ao formato de serialização novo / aprimorado não será um alvo para o msbuild, mas sim para um novo sistema de construção (o que não acontecerá tão cedo).

Também fico preocupado quando as pessoas presumem que o que fazemos é apenas adicionar e remover dependências. Talvez seja o que eles fazem porque estão apenas fazendo aplicativos do tipo 'olá, mundos'. Mas outras opções como buildOptions e overrides por moniker são extremamente poderosas e úteis. Sem mencionar que a experiência atual do editor baseado em esquema json é simplesmente incrível.

Um caminho poderia ser ter uma tarefa msbuild que carregaria project.json como alternativa. Em seguida, deixe o desenvolvedor escolher nas configurações do projeto se deseja ativar o project.json, que adicionaria essa tarefa ao csproj.

@ Mike-EEE Sim, há esperança :)

Tenho certeza de que a tendência atual é fazer com que o project.json se torne nuget.json - o que esperançosamente resolveria o problema de dependência e deixaria a maior parte da funcionalidade existente do project.json intacta.

A única coisa que não consigo descobrir é como isso afeta a multitargeting. O csproj e o nuget.json teriam que estar cientes e entender o que cada um tem como alvo? Acabamos com um csproj para cada destino (eca!), Ou eles podem estender .csproj o suficiente para dar conta disso?

project.json se torna nuget.json

Só estou curioso aqui ... onde _esta_ conversa está acontecendo? Eu entrei na equipe nuget antes por bloquear um formato específico. Em relação ao project.json, eles disseram que era uma preocupação com as ferramentas do Visual Studio e algo que não podiam resolver. Agora parece que a dinâmica mudou e copiei / colei mais do mesmo tipo de problema. : stick_out_tongue:

Para esclarecer minha preocupação, é que agora estamos misturando JSON e XML, o que produz ineficiência no mínimo.

Só por curiosidade aqui ... onde essa conversa está acontecendo?

Bem, foi originalmente declarado aqui: https://blogs.msdn.microsoft.com/webdev/2016/05/11/notes-from-the-asp-net-community-standup-may-10-2016/

É possível que o arquivo project.json permaneça e contenha todas as referências do pacote para NuGet e seja renomeado para nuget.json.

E acho que é disso que se trata a discussão aqui, quanto você retira de project.json e coloca em um .csproj? Em meus projetos, a maioria do project.json tem sido referências de pacote, principalmente se estou direcionando vários frameworks. O acima sugere que tudo isso permaneceria e apenas os "outros" bits seriam retirados. Na minha experiência (novamente: pessoal), esses "outros" bits realmente não mudam muito ao longo da vida de um projeto, então, mesmo que seja em XML, não é muito XML e deve ser bastante estático ... espera-se .

Eu concordo que misturar e combinar XML e JSON para configurações diferentes é um pouco fedorento, mas sou um pouco preconceituoso contra JSON, pois não sou um grande fã de como ele está sendo usado. Essa é definitivamente uma preferência pessoal, no entanto.

Bem, foi originalmente declarado aqui ...

Ah sim ... claro! OK. Apenas certificando-se. Esperançosamente, amanhã será o dia em que finalmente teremos alguma clareza (para melhor ou para pior!) Em torno disso.

Eu concordo que misturar e combinar XML e JSON para configurações diferentes é um pouco fedorento

Estou muito feliz por não ser o único que vê isso e se sente assim. :) Pareceu solitário lá por um tempo, enquanto eu lutava pela primeira vez contra a dor de ver .JSON se infiltrando em projetos. Totalmente faz sentido a partir de um plano de fundo web-appdev, mas o appdev nativo não gosta e vice-versa quando se trata de XML.

Haha ... falando nisso, escrever o texto acima me fez retirar os velhos arquivos. Aqui estou eu em 2014 defendendo (sim, você adivinhou!) Xaml em vez de JSON hahaha oh, olhe como eu era jovem e completamente ingênuo! Tão fofo e despretensioso! Rapaz, eu tinha o mundo para aprender. : stick_out_tongue: Mas, direi que houve ALGUNS progressos. Afinal, nos livramos daquele .ini usado para a configuração do servidor web . :sorriso:

@neoKushan Definitivamente, existe o melhor dos dois mundos.

👯 👯 👯

@neoKushan Tenho certeza de que a tendência atual é fazer com que o project.json se torne nuget.json ... A única coisa que não consigo descobrir é como isso afeta a multitargeting. O csproj e o nuget.json teriam que estar cientes de e entender o que cada um está almejando?

Usando o esquema project.json como ponto de partida, da minha perspectiva, os seguintes itens provavelmente _não_ devem estar no arquivo de definição de compilação:

• Lista de arquivos fonte
• Dependências do projeto
• Estruturas de destino
• Comandos do projeto (por exemplo, web, teste, etc)
• Webroot
• Metadados
• Versão do idioma

O seguinte, eu não _acredito_, deveria estar no arquivo de definição de compilação, mas eu _meh_ sobre isso se estivessem:

• Definições de configuração
• Scripts, pré e pós

O seguinte provavelmente _deve_ estar no arquivo de definição de compilação:

• Opções de compilação (excluindo a versão do idioma)

O acima exposto é apenas para provocar discussão. Fico feliz em debater qualquer ponto individual. Sugira ignorar como os arquivos são chamados e em que formato eles estão agora.

@shederman Precisamos esclarecer o que você quer dizer com "definição de construção"? Talvez minha terminologia esteja errada, mas eu não chamaria o project.json atual de arquivo de _build definition_, mas sim um arquivo de _project definition_ (e o mesmo seria para o novo arquivo csproj). Possivelmente semântica, mas para mim uma definição de construção sugere que ela define _como as coisas são construídas_, enquanto uma definição de projeto define o que compõe um projeto e deixa as etapas de construção para outra coisa.

_Este projeto é meu, é composto por esses itens e tem essas dependências. Como você constrói não é da minha conta._

Muito do projeto pode ser determinado apenas por convenção, como a forma como o nome do assembly vem da pasta de nível superior. Seguindo essa linha de pensamento, _nuget.json_ seria qualquer coisa a ver com nuget - então os pacotes / dependências iriam para lá e acho que estamos todos felizes com isso.

O que não consigo decidir são os frameworks de destino. Se o Nuget.json se preocupa apenas com a resolução de dependências, embora possa haver alguma separação para referências ao direcionar diferentes frameworks, não estou totalmente certo de que deve ser aquele que decide quais frameworks são realmente direcionados, isso parece algo mais para o _project definição_ (o que quer que seja).

Então, novamente, há mais no nuget do que apenas referências de pacote, ele também contém o pacote _definição_ e a versão para quando sua biblioteca _tornar-se_ um pacote nuget. Parece que o nuget.json está fazendo pelo menos duas coisas diferentes e isso está começando a cheirar mal. Talvez (apenas cuspindo aqui), o csproj definiria os detalhes do pacote, as estruturas de destino etc. e cada estrutura de destino poderia apontar para um arquivo .json, que é basicamente os pacotes nuget. Em outras palavras, em vez de um nuget.json, você teria um arquivo .json separado para cada estrutura. Pode ser uma ideia terrível, não pensei muito sobre isso.

https://blogs.msdn.microsoft.com/dotnet/2016/05/23/changes-to-project-json/ :

Tínhamos duas escolhas. Um era mover todos os projetos .NET para usar project.json. Isso exigiria que fizéssemos um trabalho de ferramentas que tocasse todos os tipos de projeto no Visual Studio, Xamarin e nossos parceiros como o Unity. Teríamos que expandir o project.json para oferecer suporte a todos os cenários de construção exigidos por cada um desses tipos de projeto e fornecer uma história de migração. Outra opção era construir pontes para que um projeto .xproj pudesse fazer referência a um projeto .csproj e um projeto .csproj pudesse fazer referência a um projeto .xproj no Visual Studio e no Xamarin Studio. A ponte também tem desafios, por exemplo, quando um cliente cria um projeto, ele agora teria que escolher um .xproj ou .csproj, o que apenas adiciona mais opções e complexidade.

E

Depois de examinar nossas opções, ficou claro que seria mais fácil mover os projetos do .NET Core para .csproj / MSBuild, de forma que todos os projetos do .NET usem as mesmas ferramentas e sistema de compilação.

Planejamos aprimorar o .csproj para oferecer suporte à funcionalidade ausente:

• Sem listagem de arquivos no sistema de projeto
• Ferramenta CLI para fazer qualquer operação no arquivo de projeto, para a maioria dos cenários você não edita o arquivo
• Construir pacotes diretamente do projeto
• Multi-segmentação

E como todo o .NET usa as mesmas ferramentas, podemos examinar como aprimorar o MSBuild. Solicitaremos feedback dos clientes e da comunidade sobre o suporte a JSON em vez de XML, fazendo com que nossas ferramentas não gerem arquivos excessivamente prolixos e muito mais. E como tudo usa as mesmas ferramentas, essas melhorias podem funcionar em todos os projetos .NET.

https://blogs.msdn.microsoft.com/dotnet/2016/05/23/changes-to-project-json/#comment -71485:

Supondo que .csproj ainda signifique Projeto C #, é claro que haverá outros alvos para projetos não C #, correto? [Ben]

sim. [Scott H]

Tenho um pouco de medo de que .net ficará preso com um sistema de compilação complexo-legado-justForTooling como msbuild, talvez devêssemos começar com ele para fazer o dotNetCore funcionar e então planejar um novo sistema de compilação moderno?
Para dar esperança a todos e fazer as coisas sem pressa de enviar .netcore.

Não preciso editar arquivos msbuild com frequência, mas quando preciso é muito difícil, a abordagem declarativa faz você se perder no fluxo, trago meu exemplo, ninguém parece ser capaz de resolver um problema simples como este https: // github .com / madskristensen / BundlerMinifier / issues / 89
Se depois de 6 meses ninguém conseguiu executar uma tarefa (duas tarefas diferentes, cada uma sem saber da outra) após a outra sem hackeamentos sujos ou de forma aditiva, talvez haja algo para consertar ali.

Obrigado

Ferramenta CLI para fazer qualquer operação no arquivo de projeto, para a maioria dos cenários você não edita o arquivo

: -1:

Sou totalmente a favor das ferramentas CLI para ajudá-lo a fazer seu trabalho, mas se eu _tender_ uma ferramenta CLI para gerenciar referências e pacotes, ficarei chateado. Install-package é ótimo, mas poder digitar apenas metade do nome do pacote e fazer com que apareça uma lista de possibilidades, com todas as suas versões, foi incrível.

As ferramentas cli são ótimas para automação, mas são uma maneira pobre de executar tarefas, exceto para as básicas como npm install ou dotnet restore . Se tivermos que aprender coisas como dotnet buildoptions define add --framework net451 SOME_DEFINE é uma merda. Esta é uma grande perda.

Uma boa história de desenvolvimento é:

• Projeto facilmente editável e arquivos de compilação
• Sistema de construção configurável
• Ferramentas cli simples, bem projetadas e completas
• Ótimo Gui, ferramentas IDE

Tornar um desses pobres (o que era ótimo antes) para tornar o outro aceitável é simplesmente estúpido.

O argumento da unidade e do xamarin é muito ruim, na verdade. Eu não acho que eles irão migrar para o núcleo .net tão cedo, e retroceder para sua conveniência é simplesmente idiota ao projetar para o futuro do .net.

E como todo o .NET usa as mesmas ferramentas, podemos olhar para o aprimoramento do MSBuild

Nenhum MSBuild será aprimorado antes de sermos forçados a ele ...

Este artigo não é realmente a postagem do blog que estávamos esperando e confirma que o núcleo .net está sendo mal orientado.

As ferramentas cli são ótimas para automação, mas são uma maneira pobre de executar tarefas, exceto para as básicas, como npm install ou dotnet restore.

Mais uma vez, sinto que essa questão é um conflito de culturas / preferências / filosofia. Em algum lugar ao longo do caminho, a CLI tornou-se uma boa ideia para substituir a GUI, quando na verdade você precisa de ambas, pois verá que os desenvolvedores (mais uma vez) têm sua preferência de abordagem. Alguma inovação é certamente necessária nesta área, pois parece que é sempre um problema: o CLI é criado, mas o GUI não e vice-versa.

Para mim, parece que uma espécie de estrutura é necessária para criar a API e, em seguida, as versões CLI e GUI são criadas automaticamente para você.

Poderíamos chamá-lo de ... CLIGUIAPI! : +1:: +1:: +1: #problemsolved

esta questão é um choque de culturas / preferências / filosofia

Definitivamente, e isso você não pode resolver, exceto abordar cada abordagem com a melhor abordagem possível. node.js e eu não sou o maior fã desta pilha fez um ótimo trabalho com a ótima ferramenta cli npm e package.json. A parte Gui é tratada por vários fornecedores (webstorm, vs código, estúdio visual). Sistemas extravagantes como gulp são cem por cento opcionais.

talvez eu seja uma minoria nisso e talvez não, mas embora goste do project.json, as razões explicadas aqui https://blogs.msdn.microsoft.com/dotnet/2016/05/23/changes-to-project -json / faz muito sentido para mim. Estou muito confiante de que terminaremos com uma boa experiência, então realmente não estou preocupado com isso e de forma alguma diminui meu entusiasmo por esses novos frameworks. As pessoas parecem muito rápidas em sair da bifurcação e agir como se fosse o fim do mundo antes mesmo de ver como será a experiência final

Parei de ler há um tempo, mas encerrarei este problema assim que tivermos uma resposta definitiva sobre project.json .

Que tal manter project.json e .csproj, onde .csproj é gerado pelo comando dotnet restore e não sincronizado no controle de versão por padrão? A diferença será, ao invés de dotnet restore gerar “project.lock.json” (e fazer outras coisas), ele irá gerar (ou atualizar) o arquivo “.csproj”. Até mesmo “project.lock.json” e “.csproj” podem permanecer, pois ambos estão sendo gerados automaticamente. Sinalizadores podem ser usados ​​em dotnet restore para gerar .csproj. No anúncio, a Microsoft já está dizendo- “Ferramenta CLI para fazer qualquer operação no arquivo de projeto, para a maioria dos cenários você não edita o arquivo”. IMHO, dotnet restore é mais adequado para ser ESSA ferramenta CLI, que terá project.json como entrada. As vantagens serão-

• Ambos os formatos de project.json e .csproj podem permanecer inalterados. Isso significa que o novo .csproj gerado será compatível com versões anteriores do Visual Studio e outras ferramentas. dotnet restore pode inserir uma lista "incluir" explícita de arquivos de projeto no arquivo .csproj.
• Como .csproj é gerado automaticamente e não no controle de versão, os desenvolvedores não precisam lidar com a edição manual e mesclagem de .csproj.

É, não.

Fechando. Tudo o que poderia ser dito foi dito.

Se você quer descobrir como ele deve ser feito e estar na equipe de design que fala sobre isso ... por favor, faça .

Caso contrário, é espaço desperdiçado e principalmente ... está enchendo caixas de entrada.

@MaximRouiller espero que você reúna os comentários que se concentram em responder às suas perguntas iniciais, apesar da quantidade de ruído.

postado ontem:

https://blogs.msdn.microsoft.com/dotnet/2016/05/23/changes-to-project-json/

@neoKushan Precisamos esclarecer o que você quer dizer com "definição de construção"? Talvez minha terminologia esteja errada, mas eu não chamaria o project.json atual de arquivo de definição de construção, mas sim de arquivo de definição de projeto (e o mesmo seria para o novo arquivo csproj). Possivelmente semântica, mas para mim uma definição de construção sugere que ela define como as coisas são construídas, enquanto uma definição de projeto define o que compõe um projeto e deixa as etapas de construção para outra coisa.

Muito bem no meu pensamento. A definição do projeto seria uma descrição puramente declarativa do que o projeto é. Metadados, versões, especificações de arquivo, etc. A definição da construção seriam as etapas executadas para converter o projeto em código executável. A definição da construção quase certamente precisaria de algo bastante rico para expressá-la, sendo o meu código favorito.

Mas, tudo parece discutível: @MaximRouiller e MS fecharam tudo. Seu feedback foi ignorado e eliminado, obrigado por ligar.

No geral, toda a coisa csproj -> project.json -> csproj foi um conjunto de decisões erradas que voltarão a assombrar a adoção do IMHO pela MS em .NET. A tendência de desenvolvedores abandonando o .NET por pastagens mais verdes continuará inabalável.

Tão triste.

@shederman Não há correlação entre um índice de Tiobe em declínio para C # e a decisão de voltar para csproj. Além disso, um índice de Tiobe em declínio não é uma indicação da saúde em declínio do ecossistema C #. Mais idiomas entrando no mercado tornam difícil para qualquer um deles manter uma grande participação no mercado.

Não estou claro sobre o impacto como um todo, mas gostaria de salientar que deve haver uma separação de avaliação de preocupações aqui. Se csproj significa apenas porque estou adicionando um arquivo, meus companheiros de equipe estão preocupados com outros impactos relacionados ao processo de construção, então estamos perdendo o barco.

csproj é algo que eu tolero, não prefiro.

@jerometerry, eu não estava dizendo que isso por si só causaria um declínio. Mas muitas das mudanças inovadoras no .NET Core visavam impedir o declínio e as perdas para a AWS. Essas mudanças estão sendo lentamente eliminadas uma a uma e, portanto, o .NET Core está se tornando cada vez mais improvável de atrair os desenvolvedores para a plataforma.

Além disso, a má tomada de decisão - que pode ser rastreada desde a decisão de introduzir o project.json até hoje não é um bom presságio.

Se os EM estão determinados a se concentrar no passado, não devem se surpreender se perderem no futuro. É improvável que o pensamento que o colocou em um problema o tire dele.

Mais idiomas entrando no mercado tornam difícil para qualquer um deles manter uma grande participação no mercado.

É verdade, mas na minha experiência, mais danos do que o necessário no .NET são causados ​​por fogo amigo.

BTW ... houve mesmo um standup ontem? Eu entrei em live.asp.net, mas a contagem regressiva acabou de reiniciar, sem vídeo / feed ou qualquer coisa ...

@ Mike-EEE Ouviram que você estava chegando: stick_out_tongue_winking_eye:

É frustrante que eles tenham feito isso. Eu escrevi sobre isso: http://www.brettmorrison.com/microsofts-little-decision-is-a-big-mistake

Do standup de hoje: https://youtu.be/YJsQ3tnS7Ew?t=38m45s

Ele aborda especificamente project.json aqui: https://youtu.be/YJsQ3tnS7Ew?t=26m12s

Embora o formato project.json seja muito mais simples de editar (a menos que você esteja no estágio de desenvolvimento do .NET de ser um macaco de conjunto de dados de arrastar e soltar), o maior problema para mim é que ninguém está se preocupando em atualizar suas bibliotecas para o. netcore. Até agora, consegui fazer um branch do Restsharp funcionar, mas ele usa o formato project.json. JSON.NET, Structuremap, NUnit etc. etc., todos têm ramificações DNX obsoletas onde parece que os desenvolvedores abandonaram a esperança.

Portanto, é um pouco estranho chamar o .NET Core RC1 / 2 de candidato a lançamento quando o formato do projeto da ferramenta de linha de comando dotnet está sendo removido. Isso para mim ainda é um software beta ou alfa, pois é experimental.

Minha principal motivação para mudar para o vNext é usar hospedagem barata de Linux e Docker. Uma ferramenta de migração de projeto o mais rápido possível, pois a maioria das pessoas será completamente prejudicada por suas bibliotecas por meio de referências de nuget sem versões do .NET Core.

@yetanotherchris dnx era um conceito em rc1, ele mudou para dotnet cli em rc2, então a maioria dos projetos dnx ou branches estariam obsoletos neste momento

project.json ainda está aqui e é necessário para rc2, discussão sobre isso ir embora no futuro após RTM

json.net também conhecido como newtonsoft.json funciona e é usado pelo próprio framework, eu também o uso em meus projetos
nunit não é compatível, todo mundo usa xunit afaik
structuremap tem uma biblioteca compatível com rc2

ainda existem muitas coisas de terceiros ainda não portadas para rc2, mas a Microsoft não controla o tempo de outros projetos e quando eles farão bibliotecas compatíveis

@yetanotherchris Se você usar importações em seu project.json, poderá especificar os monikers antigos fora do padrão de rede e ele os usará:

"frameworks": {
  "netcoreapp1.0": {
    "imports": [
      "dotnet5.6",
      "dnxcore50",
      "portable-net45+win8"
    ]
  }

É provavelmente por esta razão que muitas pessoas ainda não se preocuparam em atualizar suas bibliotecas, não há necessidade de atingir outro alvo móvel antes do RTM real.

@joeaudette Eu estava falando sobre o nome do branch (DNX) e não sobre a ferramenta de linha de comando dotnet . Muitas pessoas usam o NUnit, é basicamente o conjunto de testes de fato fora do MsTest. Não tenho certeza de onde você está encontrando os pacotes JSON.NET ou Structuremap, há uma versão não oficial do Structuremap chamada DNX e um branch Newtonsoft aqui e um .NET Standard 1.0 beta em nuget.org (o padrão .net agora é redundante até onde sei).

@neoKushan obrigado, vou dar uma olhada nisso.

Acho que meu ponto principal foi que é um pouco bobo chamá-lo de candidato a lançamento, já que vai mudar completamente para a versão final. Talvez em um mês tenhamos uma enxurrada de atividades, agora que os sistemas de construção não são completamente diferentes dos antigos e novos - embora, como alguém que é principalmente um desenvolvedor web, eu prefira project.json .

@yetanotherchris

(o padrão .net agora é redundante, tanto quanto eu sei).

O que te faz dizer isso? O Netstandard não vai desaparecer com a mudança do projeto, está aqui para ficar. Você poderá direcionar netstandards em seus futuros arquivos csproj. O padrão de rede é absolutamente essencial. Um dos principais motivos pelos quais eles estão descartando project.json é unificar todo o ecossistema .net e é isso que o netstandard também está trazendo para a mesa.

Acho que meu ponto principal foi que é um pouco bobo chamá-lo de candidato a lançamento, já que vai mudar completamente para a versão final.

Eu concordo até certo ponto com isso, embora eu não ache que isso esteja mudando tanto quanto as pessoas pensam que está. Para começar, project.json ainda vai estar aqui para o RTM, todas as mudanças acontecerão depois disso. Você pode então perguntar por que chamá-lo de "Final" se vai mudar e talvez haja um ponto aí, mas no final das contas todo o seu código e bibliotecas e tudo o que não está mudando, é apenas a _definição_ do projeto. Essa não é uma mudança tão grande quanto se poderia pensar a princípio, embora com certeza haja um pouco de diversão com a migração.

@yetanotherchris você deve lembrar que rc2 é a pré-visualização e então você deve procurar pacotes de pré-visualização de terceiros também
https://www.nuget.org/packages/Newtonsoft.Json/9.0.1-beta1
https://www.nuget.org/packages/StructureMap.Dnx/0.5.1-rc2-final

Não sei sobre o NUnit se ele terá suporte mais tarde, mas por enquanto, nos projetos .NET Core e ASP.NET Core, as pessoas estão usando o xunit
https://xunit.github.io/docs/getting-started-dotnet-core.html

@yetanotherchris Acho que todos podemos concordar que rc1 deveria ter sido rotulado como beta9, rc2 é o primeiro lançamento de qualidade rc real
project.json e outras ferramentas não fazem parte da estrutura em si, as ferramentas permanecerão em visualização e sujeitas a alterações por um tempo, mesmo quando a estrutura é RTM

Eu nem ficaria surpreso se trouxermos de volta - talvez mantenhamos um project.json, e ele só funciona em cenários limitados. Se é isso que as pessoas querem, vamos cogitar essa ideia.

Scott Hunter, dotnetConf 2016 Dia 1 Keynote 12m24s

Alguém sabe se o Sr. Hunter está no GitHub? E monitorando a conversa nos fóruns de produtos? Pelo que parece, ele está perdendo o feedback aqui.

Como gerente de programa para .NET e Visual Studio, duvido que @coolcsh honestamente tenha tempo livre.

Eu ficaria bastante horrorizado se ele não soubesse do feedback que foi dado. Talvez não todos os detalhes, mas certamente houve um retrocesso significativo.

Aqui está a sua chance de todos:
https://blogs.msdn.microsoft.com/webdev/2016/06/08/notes-from-the-asp-net-community-standup-june-2-2016/

Coloquei um dólar no frasco de gorjetas, por assim dizer. : stick_out_tongue:

tugberkugurlu pode ter chegado a algo com o comentário "de repente, os desenvolvedores corporativos de matéria escura começaram a dar feedback por trás das portas fechadas". Outra maneira que poderia ser colocada é, "nossos clientes corporativos levantaram algumas questões válidas sobre compatibilidade e seu investimento atual em nossos produtos". Embora a 'comunidade' pareça infeliz por não ter voz de leão em, bem, tudo, os clientes corporativos carregam uma grande vara: eles pagam muito dinheiro para acessar plataformas, ferramentas e suporte. Suas preocupações não serão ignoradas, nem deveriam ser. No final, o que a MS parece almejar é permitir que o número máximo de desenvolvedores construam o que desejam construir, facilmente, e também querem permitir a interoperabilidade e o compartilhamento junto com quase todos os domínios definíveis. Eles estão prometendo fazer com que o csproj seja muito mais fácil de trabalhar e muito mais capaz. Então, agora, eles estão prontos para entregar isso.

Como já disse várias vezes, sou um desenvolvedor corporativo em um grande banco, um cliente corporativo. Não fomos consultados sobre essas mudanças. Então, QUEM foram exatamente os "desenvolvedores corporativos de matéria escura"? Essa informação é aparentemente ultrassecreta. 007 coisas de nível.

É muito bom afirmar que os clientes corporativos carregam consigo um grande bastão, mas aparentemente apenas ALGUNS deles conseguem. Quais? Com base em quais critérios? Como entramos nessa lista de privilégios? Qual é o nível de parceiro? Qual gasto anual? Mentes questionadoras querem saber quanto EXATAMENTE precisamos pagar à MS antes de realmente ouvirem nossas opiniões?

@shederman você é um desenvolvedor móvel empresarial ou um desenvolvedor UWP empresarial? Ou Enterprise Unity Dev?

Nenhuma das acima. Escrevemos sistemas centrais para gerenciamento de ativos e integração bancária. Algumas coisas online também.

@shederman Eu suspeito que pode ser por isso que você não foi questionado?

Por favor, esclareça?

Você está realmente dizendo que os únicos desenvolvedores corporativos que a MS oferece agora são aqueles que fazem trabalho móvel para 1% do mercado, aplicativos UWP para, uns, 5% dos usuários que se importam, e desenvolvimento de jogos? De todo o espectro de desenvolvimento, a MS está virando as costas para tudo, menos para isso ?

Umm. Não.

Estou dizendo que as mudanças aconteceram depois de conversar com _aqueles_ grupos, então é por isso que você não foi questionado. A Microsoft deve oferecer suporte a todos os seus desenvolvedores, não apenas aos desenvolvedores de asp.

Sim, então se eles vão oferecer suporte a todos os seus desenvolvedores, talvez eles devam falar com todos os desenvolvedores. Talvez apenas conversar com um subconjunto selecionado de 5% dos desenvolvedores corporativos não seja uma boa maneira de avaliar as opiniões dos desenvolvedores corporativos como um todo.

Então, para que a opinião de um grande banco seja ouvida, devemos mudar todo o nosso desenvolvimento para UWP / Unity / Mobile?

Isso é ridículo.

talvez eles devam falar com todos os desenvolvedores.

Não é isso que eles têm feito nos últimos 2 anos ou mais?

@shederman Então, só porque _você pessoalmente_ não foi perguntado, você está insinuando que ninguém mais que cobre a sua área de desenvolvimento estava envolvido?

Além disso, pare de inventar esses números - isso é ridículo.

@poke , estou perguntando quem

Na verdade, pensei que os números eram bastante generosos, mas tudo bem.

@shederman , acho que você está se literalmente anos . Você só precisa olhar ao redor para ver que muitas pessoas querem mais do núcleo .net.

Há também a questão das solicitações reais de suporte corporativo de grandes organizações que desejam saber como transportar seu material existente para uma plataforma cruzada - você provavelmente não foi "Questionado" porque não exigiu que alguém da Microsoft lhe dissesse o que que você está tentando fazer está além do escopo do projeto.

Outra maneira de ver isso - e da maneira que eu pessoalmente vejo - é que perguntaram a você, perguntaram a você no segundo em que o anúncio foi feito, meses atrás. Apesar de todos os gritos de pessoas dizendo que as decisões foram tomadas sem consultar ninguém, a Microsoft afirmou repetidamente que ainda está trabalhando nos detalhes, que ainda não reuniu as peças finais e agora é a hora de expressar sua opinião . Scott Hunter até disse que se as pessoas _realmente_ quiserem o project.json como uma opção, elas considerarão mantê-lo. Vá assistir a palestra dotnetconf se você não acredita em mim.

@neoKushan Agradeço que Scott recuou um pouco, dizendo que considerariam mantê-lo, mas realmente precisa haver um ponto único e centralizado para as pessoas expressarem que é isso que desejam, caso contrário, o problema project.json continuará aparecendo discussões em todos os lugares. Isso também significa que, quando é trazido à tona, todos podem responder com o mesmo "ei, eles vão considerar mantê-lo se os desenvolvedores realmente quiserem, aqui é onde você vai informá-los".

project.json foi um bom passo. Mas foi ingênuo em minha opinião. Não leva em consideração que as pessoas gostariam de ter projetos híbridos escritos em C ++ ou F #. Algumas de suas primeiras decisões de design, como dnx e o uso de nuget como unidade de montagem, não eram viáveis ​​para o ecossistema dotnet como um todo. O que você está vendo é que, no processo de trazer harmonia ao dotnet, eles precisam fazer essas escolhas difíceis.

Fazer bifurcações e reinventar, em minha opinião, não ajudará o ecossistema dotnet, apenas o prejudicará. Node e Go (especialmente Go) são muito atraentes para iniciantes porque têm plataformas / ferramentas homogêneas e consistentes.

Acho todo o argumento XML vs JSON bobo porque em outros 5 anos, será JSON vs YAML e depois YAML vs Groovy (por exemplo, gradle). XML não é tão perverso como todos vocês fazem parecer. O MSBuild está muito amadurecido e tem muito investimento que vai beneficiar a todos.

Dito isso, MUITO trabalho precisa ser feito com o MSBuild para garantir que você obtenha o mesmo ou pelo menos uma maneira menos dolorosa de usar e editar arquivos csproj. Em seguida, mova as dependências do nuget para um arquivo nuget.json. Use a Convenção sobre a Configuração para que, se você estiver no "caminho da felicidade", seu csproj esteja quase vazio, um pouco como o web.config hoje. e ter opções cli que ajustam o csproj

Para mim, vou sentir falta do project.json, mas não pelos motivos que você pensa. Projetos em C # ficarão bem. Sentirei falta por causa do F #. Prefiro editar project.json para a ordem de compilação em vez de editar msbuild. Novamente, não porque o xml é mau, mas porque os arquivos fsproj têm muitos inchaços causados ​​pelo msbuild

Meu problema com essa decisão foi principalmente o modo como o arquivo csproj era menos sobre xml / json e muito mais sobre o que eles optaram por incluir no arquivo csproj. Continha a definição do projeto, as configurações do IDE, as etapas de construção, as referências ...

Não há muita coisa que _não_ termine nessa coisa. Isso o tornou terrível e só é agravado quando temos que lidar com o msbuild sendo bastante misterioso às vezes. Se você estiver honestamente interessado em tornar o .NET Core bom e não apenas funcionar, torne o arquivo de projeto agnóstico para construir ferramentas. Devo ser capaz de especificar qual é meu projeto e do que depende, separadamente de como construí-lo. Sem mencionar que isso começa a nos permitir a escolha das ferramentas, mesmo que a opção inicial seja apenas apoiada pelo msbuild agora.

Eu concordo com isto. No final do dia, o principal problema com csproj é que
faz tudo.

Eu gosto do meio-termo que PatriotBob está sugerindo ...

Na terça - feira, 21 de junho de 2016 às 13h28, PatriotBob

Meu problema com essa decisão foi principalmente a forma como o arquivo csproj era menor
sobre xml / json e muito mais sobre o que eles escolheram incluir no csproj
Arquivo. Ele continha a definição do projeto, continha as configurações do IDE,
continha etapas de construção, contém referências ...

Não há muita coisa que _não_ termine nessa coisa. Isso fez com que
terrível e só é agravado quando temos que lidar com o msbuild sendo
bastante misterioso às vezes. Se você for honesto, interessado em tornar o .NET Core bom
e não apenas o trabalho torna o arquivo do projeto agnóstico para a construção de ferramentas. eu deveria
ser capaz de especificar qual é o meu projeto e do que depende, separado de
como construí-lo. Sem falar que isso começa a nos permitir a escolha de
ferramentas, mesmo se a opção inicial for apenas apoiada por msbuild agora.

-
Você está recebendo isto porque comentou.
Responda a este e-mail diretamente, visualize-o no GitHub
https://github.com/aspnet/Home/issues/1433#issuecomment -227511911 ou mudo
o segmento
https://github.com/notifications/unsubscribe/AKh-zsedLYg_PToadpD-_ewZPci0oHGCks5qOB8rgaJpZM4IcGCt
.

Todo o XML é ruim, JSON é uma grande comoção foi muito exagerada. Gosto do que PatriotBobo está dizendo.

gerenciar as / w projeto inteiramente de npm 's package.json nunca foi tão simples e concisa declarar meu projeto, construir meu projeto, atualizar meu projeto (por exemplo, greenkeeper), ler / escrever / analisar dados sobre meu projeto, e publicar meu projeto tão fácil. _tão fácil. como muitos de nós, minha história está em c ++ / java / python / node, com jogo em outros. Anseio pela experiência de npm em todos os meus projetos agora.

os project.json prometiam produzir essas mesmas características. Acho que é um modelo que vale a pena imitar, sem sacrificar a simplicidade e o poder.

se a equipe principal da equipe .net achar que a outra solução pode fornecer essas características, excelente e poder para elas! no entanto, não prejudique a beleza da simplicidade à medida que avança.

Além disso, eu entendo que a essa altura sou apenas um ruído em um fio gigante. talvez os moderadores devessem considerar fechá-lo e lidar com a provação de uma forma mais controlada. muitos comentários bons. talvez um pouco de trollagem também: $ :)