msbuild 🚀 - Considere melhorar o formato e a estrutura do projeto (POCO serializado / Agnóstico de formato) | bleepcoder.com (2024)

Obrigado por sua contribuição @SolalPirelli. Não tenho certeza do que você quer dizer com adicionar complexidade. A solução / objetivo é reduzir a complexidade e, ao mesmo tempo, satisfazer as preferências do desenvolvedor (e organizacional). Mesmo que o conjunto de ferramentas deva ser usado exclusivamente pelo VS / IDE, isso não significa que os humanos não sujam suas mãos com ele, e o fazem o tempo todo. O processo para fazer isso é muito desajeitado e desajeitado (ao que acredito que você alude por meio de "histórico").

Eu também o desafiaria sob demanda para JSON x XML. Que fóruns / tweets _você_ tem lido? :sorriso:

Não tenho certeza do que você quer dizer com adicionar complexidade.

Adicionar suporte para vários formatos de arquivo necessariamente aumenta a complexidade. Significa adicionar uma API pública que os provedores de terceiros usarão, o que definitivamente causará dor de cabeça quando novos itens forem adicionados e descobrir que os provedores estavam fazendo coisas malucas para habilitar DSLs.

Eu também o desafiaria sob demanda para JSON x XML. Que fóruns / tweets você tem lido?

Se isso for resolvido por meio de fóruns e tweets, acabaremos escrevendo nosso arquivo de configuração em Go, JavaScript ou Rust.
O formato de marcação exato não importa, o que importa é que o formato resultante é editável por humanos e programas, adaptado às necessidades atuais e preparado para evolução futura. Não há nada em JSON que o torne claramente melhor do que XML nesse aspecto. Na verdade, JSON é pior porque não tem comentários.

I would also challenge you on demand for JSON vs. XML. What forums/tweets have you been reading?

Eu vou te desafiar de volta; nunca em um ambiente profissional, por alguém que eu consideraria um desenvolvedor profissional (ou Build Master), eu diria que ouvi um pedido de mudança para um MSBuild baseado em JSON.

Concordarei com relação à documentação e solicitarei que o formato XML atual seja melhor documentado; mas, no que diz respeito à mudança para JSON, vejo pouco ou nenhum ganho técnico. Por que não usar esses recursos que seriam desperdiçados em tal sistema e, em vez disso, colocá-los no aprimoramento dos documentos do MSDN?

De acordo com Raymond Chen, cada recurso começa em -100; quais são os ganhos que nos levam a Positivo 100?

Se isso for resolvido por meio de fóruns e tweets, acabaremos escrevendo nosso arquivo de configuração em Go, JavaScript ou Rust. Se isso for resolvido por meio de fóruns e tweets, acabaremos escrevendo nosso arquivo de configuração em Go, JavaScript ou Rust.

LOL!!!

Eu te escuto. Quanto à API. Sim, esse é o objetivo aqui. Para (em última análise) ter uma API de projeto bem definida / documentada / acessível que todos nós conhecemos e temos disponibilidade para, caso queiramos saber o arquivo (projeto) que estamos realmente descrevendo. :)

Quando você abre um arquivo .csproj agora ... você pode, com toda a honestidade, dizer que conhece cada um dos elementos dentro dele? O esquema é, na melhor das hipóteses, difícil de descobrir e navegar. Considerando que, se estivéssemos usando uma API bem conhecida (.NET POCOs), isso se tornaria um piscar de olhos.

Na verdade, JSON é pior porque não tem comentários.

Concordou. Mas nem todos estão de acordo com isso. E também, estou sugerindo JSON5, que permite comentários. Por fim, a serialização deve ser um detalhe de implementação, e não algo que faça parte do MSBuild, por si só. Ele apenas tem que apoiá-lo.

Eu vou te desafiar de volta; nunca em um ambiente profissional, por alguém que eu consideraria um desenvolvedor profissional (ou Build Master), eu diria que ouvi um pedido de mudança para um MSBuild baseado em JSON.

Bem, caras ... ONDE VOCÊ ESTAVA NA MINHA VIDA NOS ÚLTIMOS ANOS?!?! LOL. Acho que tenho uma baaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa, porque eu tenho insistido contra o movimento project.json por mais de um ano agora e parece ter sido uma batalha dificil, para dizer o minimo!

Pessoalmente, estou muito mais no campo XML (na verdade, prefiro ver o Xaml), mas quero considerar e estar atento aos desenvolvedores que têm aproveitado o novo brinquedo brilhante do project.json no ano passado.

Quando você abre um arquivo .csproj agora ... você pode, com toda a honestidade, dizer que conhece cada um dos elementos dentro dele?

Sim; isso é o que significa ser um Build Master e colocar em seu currículo que você fala MSBUILD. Eu sei que a comunidade teve um influxo recente de posers do movimento "DevOps"; mas ainda existem poucos que realmente sabem o que estão fazendo além de uma interface drag n 'derp.

O esquema é, na melhor das hipóteses, difícil de descobrir e navegar.

Esta é a cartilha para quem está entrando no MSBuild e precisa começar com https://msdn.microsoft.com/en-us/library/0k6kkbsd.aspx Lendo Sayed Ibrahim Hashimi's "Por dentro do Microsoft Build Engine: Usando o MSBuild e o Team Foundation Build "também deve ser leitura obrigatória para qualquer pessoa que afirme ter conhecimento íntimo.

ONDE VOCÊ ESTAVA NA MINHA VIDA NOS ÚLTIMOS ANOS?!?!

Monitorar o andamento do open source do MSBuild; tentando ajudar no StackOverflow sob a tag MSBuild (quando Sayed não está me vencendo). #JustBuildMasterThings

Quero considerar e estar atento aos desenvolvedores que têm aproveitado o brinquedo novo e brilhante do project.json no ano passado.

Não vejo razão para que ambos os projetos não possam coexistir; deve-se permitir que cada projeto falhe ou tenha sucesso com base em seus méritos técnicos. Em vez de perseguir os faróis traseiros, pessoalmente acho que os recursos são mais bem gastos para melhorar o que temos se houver um ganho técnico claro. Dito isso, não sou o Product Owner, nem mesmo um desenvolvedor, apenas um usuário final bem informado.

mas simplesmente suportá-lo como um mecanismo de serialização

Novamente, o que é realizado a partir disso?

Sim; isso é o que significa ser um Build Master e colocar em seu currículo que fala MSBUILD

Bem, tudo isso é muito bom e é ótimo ver todos os seus investimentos / compromissos para se tornar / ser um Build Master, mas para um desenvolvedor típico que simplesmente deseja adicionar uma nova tarefa ao seu projeto para fazer x, y, z, seus O objetivo é fazer com que essas tarefas entrem e voltem ao desenvolvimento de código, sem gastar uma semana em leituras obrigatórias para descobrir os recursos mais simples.

Novamente, o que é realizado a partir disso?

Você está me perguntando o que é possível permitir que os desenvolvedores usem o formato no qual eles preferem trabalhar? : smile: Os desenvolvedores da Web realmente gostam de seu JSON e os desenvolvedores nativos realmente gostam de seu XML / Xaml. Tããão ...

E, claro, existem outros formatos que os desenvolvedores gostam. Ao adotar e habilitar o suporte para eles (o que pode ser feito por terceiros, não do próprio MSBuild ), você incentiva a adoção.

Todos concordam que precisamos de um formato menos misterioso para os arquivos de construção. Não posso falar pela Microsoft, mas parece que eles também querem seguir nessa direção.

O que você parece não entender é que não se pode simplesmente "habilitar o suporte para provedores terceirizados" ligando um botão em algum lugar. Criar uma API flexível o suficiente, documentá-la e controlá-la está longe de ser trivial, MSBuild ou outro.

desenvolvedor típico que simplesmente deseja adicionar uma nova tarefa ao seu projeto para fazer x, y, z

Seria útil entender o que você está pedindo ao projeto. Olhando para o project.json (nunca tinha ouvido falar desse projeto até hoje), só vejo limitações no que sou capaz de fazer. Por um lado, não há capacidade aparente para mim de estender seu sistema de projeto com tarefas personalizadas (algo que qualquer um que utilize o MSBUILD acabará por fazer).

O conceito de gerenciamento de pacote NuGet nativo parece bom; mas dificilmente é uma novidade.

não gastar uma semana em leitura obrigatória para descobrir os recursos mais simples.

Mais uma vez, se você pudesse nos dizer quais são as características que você acha difíceis de descobrir e que levariam uma semana para ler?

Na realidade, uma parte significativa dos desenvolvedores nunca se verá editando manualmente o csproj ou qualquer outro arquivo baseado em msbuild. A grande maioria deles está interagindo com o sistema via Visual Studio. Aqueles que estão editando esses arquivos geralmente estão lendo a documentação ou usando wrappers no sistema, como TeamCity, Jenkins ou Team Foundation Server (TFS / Visual Studio Online como você quiser chamá-lo atualmente).

Se você está tentando atingir um público que não está usando o Visual Studio, eles devem ser encorajados a procurar o sistema de projeto recomendado de escolha para seu ambiente.

mais prefere trabalhar?

Estou perguntando o que esses desenvolvedores estão fazendo e por que não estão usando as ferramentas fornecidas a eles.

Ao adotar e habilitar o suporte para eles (o que pode ser feito por terceiros, não do próprio MSBuild), você incentiva a adoção.

Isso é ótimo em teoria; no entanto, na prática, isso resulta na formação de um contrato entre a Microsoft e esses terceiros; Raymond Chen fala longamente sobre esses assuntos, pois são um tema recorrente na história dos produtos desenvolvidos pela Microsoft. Oferecer tal sistema resulta apenas em dívida técnica adicional e, a menos que haja um motivo extremamente convincente, a maioria das equipes é sábia para não assumir tal dívida.

Mas voltando à sua postagem original, pois sinto que estamos longe do assunto

O formato MSBuild está baseado em um esquema arbitrário, não bem definido / conhecido (difícil de explorar e descobrir).

Você precisa qualificar o que você quer dizer com isso; o esquema fornece um XSD pelo qual o arquivo do projeto pode ser validado http://schemas.microsoft.com/developer/msbuild/2003 isso não o ajuda se você estiver usando tarefas personalizadas, para as quais você deveria ter fornecido o XSD quando você escreveu as tarefas. Muitos projetos baseados na comunidade, como o MSBuild Extension Pack e as MSBuild Community Tasks, fazem isso.

O formato está bem documentado no MSDN (https://msdn.microsoft.com/en-us/library/0k6kkbsd.aspx), uma exploração da sintaxe do projeto é relatividade direta para mim pessoalmente.

Se você pudesse dar um exemplo específico de uma tarefa comum em que os desenvolvedores estão se engajando, que é dificultada pelo formato atual, ajudaria a entender sua solicitação.

Crie um modelo de objeto .NET bem definido e conhecido que defina o modelo do projeto (API do projeto)

Acredite ou não, o que você pede já existe para o MSBuild; no entanto, oficialmente, não é um binário autorizado para uso de terceiros e as APIs não têm garantia de alteração. No entanto, com base no uso generalizado, tornou-se um fato (provavelmente para desagrado da equipe). A maior parte da API em questão reside no Microsoft.Build; o mais familiar para mim é o Microsoft.Build.Evaluation (https://msdn.microsoft.com/en-us/library/microsoft.build.evaluation.aspx).

Qualquer pessoa que tenha feito um mergulho profundo na criação de tarefas personalizadas ou na extensão do Visual Studio estará familiarizada com essas APIs.

Talvez uma pergunta melhor à equipe seja tornar essas APIs sancionadas de modo que os terceiros mencionados por você possam escrever de acordo com a especificação de forma mais confiável.

isso não o ajuda se você estiver usando tarefas personalizadas, para as quais você deveria ter fornecido o XSD quando escreveu as tarefas

Isso parece - e é - muito trabalho. : stick_out_tongue: O objetivo / perguntar aqui é tornar isso mais um modelo baseado em POCO, onde estamos trabalhando com POCOs bem conhecidos / bem definidos, e os objetos que são serializados / desserializados são esses objetos. Caso contrário, estamos pedindo aos desenvolvedores que adicionem "mais um artefato" com um arquivo .xsd (eles ainda são usados ​​atualmente?) Para usar como um esquema quando já tiverem definido o esquema com o objeto Tarefa que criaram.

Se você pudesse dar um exemplo específico de uma tarefa comum em que os desenvolvedores estão se engajando, que é dificultada pelo formato atual, ajudaria a entender sua solicitação.

Estou aberto a admitir que posso (muito provavelmente) usar palavras erradas ao descrever meu problema. Sou fundamentalmente preguiçoso e não gosto de pensar nas coisas até que realmente importe, como você está me pressionando a fazer! Essencialmente, existem dois cenários aqui a serem considerados:

1) Construir mestre (especialistas)
2) Desenvolvedores (script kiddies / interessados ​​em se tornar um mestre de compilação - ei, sou eu! _ )

Falarei da minha perspectiva (desenvolvedor - mas tenho muita experiência com servidores de compilação TFS). Para começar, fornecerei contexto quando for abrir um arquivo Xaml. Quando abro um arquivo Xaml, todos os símbolos desse arquivo - independentemente do tipo - ficam facilmente acessíveis para mim. Usando o ReSharper, posso CTRL-B qualquer símbolo nesse arquivo e serei levado à sua definição (descomilada). Isso acontece sempre, sem dúvida.

Agora, para o MSBuild, preciso abrir o projeto para editá-lo. Primeiro, ele produz um diálogo muito perturbador se eu quiser fechar todos os arquivos do projeto para visualizar este arquivo. Em segundo lugar, uma vez que o arquivo é aberto, a descoberta é quase zero. Sem mencionar que o paradigma conceitual em jogo é muito estranho. Se eu quiser obter uma lista de arquivos, tenho que trabalhar com essas tags PropertyGroup e ItemGroup e trabalhar com uma sintaxe estranha para coletar meus arquivos.

Já no Xaml, pude ver algo mais bem formado, como:

<msbuild:Project> <msbuild:Project.Resources> <msbuild:FileList x:Name="FilesToDelete" Files="SomeDirectory/**.*" /> <msbuild:Project.Resouces> <msbuild:Project.Tasks> <msbuild:DeleteFilesTask Files="{x:Reference FilesToDelete}" /> </msbuild:Project.Tasks></msbuild:Project>

(note que é um esboço REALMENTE RÁPIDO do que eu possivelmente gostaria de ver em um modelo de API. Por favor, não faça muito piada com isso.: stick_out_tongue: Mas o ponto aqui é que enquanto eu estou digitando, o ferramental entra em ação e Sou capaz de fazer referência a tarefas conforme as escrevo, pois são POCOs resolvidos para assemblies que referenciei.

Estou perguntando o que esses desenvolvedores estão fazendo e por que não estão usando as ferramentas fornecidas a eles.

Esse é o problema. Esta não é uma ferramenta fornecida para a edição XML de arquivos MSBuild. Bem, existe, mas é muito proibitivo quando comparado, digamos, com a experiência de edição do Xaml.

Talvez uma pergunta melhor à equipe seja tornar essas APIs sancionadas de modo que os terceiros mencionados por você possam escrever de acordo com a especificação de forma mais confiável.

Como eu disse, isso é apenas para começar a conversa. Parece que postei no lugar certo! : smile: Obrigado por fornecer sua opinião / perspectiva. Posso dizer que você sabe do que está falando! E também, dê-me seu identificador do Twitter para que eu possa marcá-lo quando for pego pela multidão JSON. (brincando ... sorta: sorria:)

O que você parece não entender é que não se pode simplesmente "ativar o suporte para provedores terceirizados" ligando um botão em algum lugar

Não foi exatamente isso que a equipe ASP.NET Core fez com sua API de provedor de configuração ? Essa é praticamente a mesma ideia aqui.

Não foi exatamente isso que a equipe ASP.NET Core fez com sua API de provedor de configuração? Essa é praticamente a mesma ideia aqui.

A equipe ASP.NET optou por aceitar modelos de configuração de terceiros, sim, e tenho certeza de que eles tinham bons motivos para fazer essa troca; o fato de que eles precisavam implementar vários provedores de configuração de qualquer maneira para coisas como vars de ambiente e arquivos de configuração provavelmente foi levado em consideração nessa discussão. Em troca dessa flexibilidade, eles ganham mais complexidade.

No entanto, você não forneceu um bom argumento sobre o motivo pelo qual o MSBuild deve se tornar mais complexo. "É a moda atual no desenvolvimento da web" não é um bom argumento.

Todo este tópico parece o problema XY para mim: você quer ter um formato MSBuild melhor, o que é ótimo, mas você acha que isso só pode ser alcançado por meio de sua ideia - permitir que todos forneçam seus próprios formatos - quando há muitos outros soluções lá fora.

@ Mike-EEE O problema é mais que você conhece as APIs XAML e (reconhecidamente) a experiência do editor é menos amigável para o MSBuild. Mas se você realmente deseja aprender http://www.amazon.com/Inside-Microsoft-Build-Engine-Foundation/dp/0735645248?ie=UTF8&psc=1&redirect=true&ref_=oh_aui_detailpage_o00_s00

Você pode contar comigo no acampamento project.json, embora o que eu amei nele foi a simplicidade:

• aqui está o nome e a descrição do meu projeto
• aqui estão os frameworks de destino que desejo suporte e aqui estão as dependências para cada
• aqui estão minhas dependências independentes de framework (na maioria das vezes, nenhuma)
• feito. Aqui está o seu pacote NuGet.

Não me importa o formato que você usa para instruir o conjunto de ferramentas a construir meu projeto, desde que esteja documentado, posso editá-lo manualmente (porque às vezes o NuGet fica confuso) e posso usar exatamente a mesma coisa em uma dev box como em um servidor de compilação e ambos funcionam exatamente da mesma maneira.

Ah, e eu não preciso manter vários arquivos, um para o VS para construir meu projeto e outro para o NuGet para empacotá-lo. Ei, VS, se você conseguir descobrir como construí-lo, tenho certeza que conseguirá coletar tudo e fazer um bom pacote para mim.

Ah, e eu não preciso manter vários arquivos, um para o VS para construir meu projeto e outro para o NuGet para empacotá-lo. Ei, VS, se você conseguir descobrir como construí-lo, tenho certeza que conseguirá coletar tudo e fazer um bom pacote para mim.

Veja https://github.com/nuproj/nuproj por @terrajobst

No entanto, você não forneceu um bom argumento sobre o motivo pelo qual o MSBuild deve se tornar mais complexo. "É a moda atual no desenvolvimento da web" não é um bom argumento

Novamente, não tornando mais complexo, mas reduzindo sua complexidade. Não é apenas um modismo no desenvolvimento da web, mas um padrão viável e popular que tem sido usado há algum tempo no .NET . A solicitação seria utilizar esse padrão para serializar objetos que são usados ​​para descrever projetos MSBuild de uma forma que permita aos desenvolvedores / organizações / equipes usar o formato de sua preferência.

Estou começando a achar que devemos esperar até que mais desenvolvedores do campo pró-JSON encontrem seu caminho para este segmento antes de tentar fornecer um argumento melhor. ;)

Todo este tópico parece o problema XY para mim: você quer ter um formato MSBuild melhor, o que é ótimo, mas você acha que isso só pode ser alcançado por meio de sua ideia - permitir que todos forneçam seu próprio formato - quando há muitos outros soluções lá fora.

Haha ... isso é legal. Eu aprendi algo novo hoje. Obrigado pelo link: smile: Minha ideia é fornecer um _modelo_ melhor (com o qual parece que todos concordam!) Que pode ser serializado / desserializado em _qualquer_ formato, se isso ajudar a esclarecer minha posição.

com um arquivo .xsd (estes ainda são usados ​​atualmente?) para usar como um esquema quando eles já definiram o esquema com o objeto Tarefa que eles criaram.

Sim; eles são usados ​​o tempo todo. Em seu exemplo Xaml, é como o Intellisense (e outras ferramentas semelhantes) sabe o que apresentar a você e como os arquivos XML são validados como "bem formados". O JSON Kids ainda não cresceu o suficiente para entender por que tais sistemas são necessários; parece que eles estão começando a mudar com base em uma rápida pesquisa no Google.

Quando abro um arquivo Xaml, todos os símbolos desse arquivo - independentemente do tipo - ficam facilmente acessíveis para mim.

Você está pedindo Intellisense; novamente fornecido por um XSD válido que é carregado automaticamente de acordo com a diretiva no topo de cada arquivo de projeto msbuild bem formado. Fora da caixa, isso é fornecido apenas para as tarefas "básicas" do MSBuild incluídas.

O fornecido no Visual Studio não atende às suas necessidades? Abaixo está uma captura de tela de um de nossos scripts de compilação mostrando isso em ação:

Uma pergunta razoável, eu acho, é pedir mais documentação de contexto aqui para melhorar a capacidade de descoberta; no entanto, isso é para outro assunto; uma que eu votaria de bom grado, pois sabia quando estava começando, era frustrante continuar a consultar a documentação.

Primeiro, ele produz um diálogo muito perturbador se eu quiser fechar todos os arquivos do projeto para visualizar este arquivo.

Esta é uma limitação do Visual Studio; não do formato de arquivo escolhido.

nenhuma ferramenta fornecida para edição XML de arquivos MSBuild

Novamente, qualquer editor compatível com XML pode fazer isso; Eu pessoalmente recomendo o Visual Studio simplesmente porque ele analisará o XSD e qualquer outro namespace incluído para fornecer a você o preenchimento contextual do IntelliSense / Código.

E também, dê-me seu nome no Twitter

Disseram-me que preciso de um; mas, honestamente, nunca me preocupei em chegar lá. Sinta-se à vontade para me @mencionar em qualquer lugar no GitHub.

Veja https://github.com/nuproj/nuproj por @terrajobst

É, não. Isso ainda exige que eu duplique informações. A única razão pela qual eu deveria precisar especificar alguma informação novamente é porque eu quero que seja diferente de qualquer outro lugar. Por exemplo, se eu tiver AssemblyInfo.cs em meu projeto e quiser que as versões do assembly sejam diferentes da versão do pacote NuGet, eu especificaria cada uma. Caso contrário, definir um deve fluir para o outro.

Devo ser capaz de descrever tudo sobre meu projeto em um único local. Também não devo precisar dizer ao NuGet que desejo pegar a saída do meu projeto e usá-la no pacote. Por que eu não gostaria de incluir isso? E se eu já especifiquei para quais frameworks gerar assemblies, por que preciso explicar quais destinos estão sendo empacotados, novamente? Escolha todos eles, a menos que eu diga o contrário.

Padrões sensatos e um mecanismo para substituí-los ...

Você está pedindo Intellisense

Na verdade, não, estou pedindo mais do que isso (pelo que entendi). O Intellisense completa os símbolos e fornece dicas de ferramentas, mas para realmente mergulhar no símbolo e levá-lo diretamente ao arquivo de classe onde ele existe, ou seja, um detalhe de implementação de IDE (ou ferramenta, como ReSharper).

O fornecido no Visual Studio não atende às suas necessidades?

Tudo bem. Mas acho a experiência Xaml muito mais expressiva e detectável. E intuitivo também. E não estou totalmente certo de que o Xaml está usando arquivos .xsd, a menos que eles os estejam criando automaticamente a partir das definições de classe. Isso parece ineficiente, pois as definições de classe já estão na memória e disponíveis para as ferramentas. Não faz sentido criar um arquivo totalmente novo e usá-lo para navegação / informação.

Além disso, outro aspecto que estamos esquecendo aqui são os arquivos .SLN, que são seus próprios animais (besta, mais parecido!) Juntos e devem ser domesticados / consolidados / considerados neste novo modelo também.

@ colin-young porque é tudo MSBuild, você pode "embuti-lo" no projeto existente e fazer com que ele extraia as informações de lá. Acho que vou fazer um fork para adicionar um exemplo de como fazer isso ...

Eu adicionei # 614 para discutir uma melhor experiência de edição do XML, uma vez que isso está fora do tópico deste problema

@ colin-young

Se eu entendi o que você está pedindo, você quer um fluxo de trabalho no qual a criação do pacote NuGet esteja mais intimamente ligada à construção; isso já é possível no MSBuild; exigiria que você adicionasse um novo destino ao arquivo msbuild existente e então chamasse o destino no momento apropriado; se você estivesse usando as tarefas da comunidade do MSBuild, chamaria a tarefa NuGetPack conforme apropriado (aqui está um trecho de um de nossos projetos):

<NuGetPack File="%(NSPSTransformed.Identity)" OutputDirectory="$(BuildOutputNuGet)" Properties="Configuration=Release" IncludeReferencedProjects="true" ToolPath="$(nugetToolPath)" />

Lendo nas entrelinhas, você quer um sistema que faça isso para você de forma automática; Não tenho certeza de que necessidades específicas de negócios devam ser atendidas pela ferramenta por padrão. Em algum momento, você precisará personalizar e modificar as ferramentas para atender às suas necessidades.

@ Mike-EEE

mas para realmente mergulhar no símbolo para levá-lo diretamente para o arquivo de classe onde ele existe

Não está claro o que você ganharia em ver o código-fonte de uma tarefa como "Mover" ou "Copiar" 99% das vezes, a menos que você esteja depurando um bug nessas tarefas e esteja mais interessado em quais atributos (argumentos ) para a tarefa e qual é o seu comportamento; tudo isso pode ser embutido no XSD; a versão fornecida e mantida é muito simplista, cobrindo apenas as tarefas integradas e os vários atributos ("argumentos" do IE) a serem passados ​​para a tarefa.

E intuitivo também. E não tenho certeza se o Xaml está usando arquivos .xsd

É um pouco mais complexo do que o fato de que o Intellisense utilizará métodos como a coleta de comentários em documentos XML para gerar essas informações instantaneamente; mas os resultados finais são os mesmos.

Não faz sentido criar um arquivo totalmente novo e usá-lo para navegação / informação.

Por que não? O arquivo é criado na memória, se houver alguma.

Além disso, outro aspecto que estamos esquecendo aqui são os arquivos .SLN, que são seus próprios animais (besta, mais parecido!) Juntos e devem ser domesticados / consolidados / considerados neste novo modelo também.

Se você observar como o MSBuild trata os arquivos SLN; eles são realmente transformados pelo MSBuild em arquivos pseudo MSBuild antes da execução para evitar a maldade incorrida neles. No entanto, tendo dito isso, achei o formato direto; se você criou outra página de problema para veicular suas reclamações, tenho certeza de que podemos mostrar como eles funcionam.

Eles também podem ser editados por meio da API vinculada acima.

Não está claro o que você ganharia em ver o código-fonte de uma tarefa como "Mover" ou "Copiar" 99% das vezes, a menos que esteja depurando um bug nessas tarefas se estiver mais interessado em quais atributos (argumentos ) para a tarefa e qual é o seu comportamento

O que você ganha é uma sensação de descoberta e acesso - não apenas para os itens padrão descritos pelo xsd, mas _qualquer objeto definido_ no arquivo. Você obtém uma conexão clara com os dados que está descrevendo e o objeto que acaba usando esses valores. Se você não passou muito tempo no Xaml, pode não fazer sentido para você, mas quando você tem acesso ao seu código e pode navegar facilmente por suas propriedades e definições, não apenas obtém um melhor entendimento dos elementos em jogo , mas também para o sistema como um todo. Isso é o que é tão incrível no .NET em geral: ser capaz de explorar elementos e ver como todos eles se conectam e como podem ser utilizados.

Por que não? O arquivo é criado na memória, se houver alguma.

Novamente, não tenho certeza se isso acontecerá. Você pode fornecer um recurso mostrando que os XSDs são usados ​​para o intellisense? Esta é a primeira vez que ouço isso. E se um processo está criando "mais um arquivo" - mesmo na memória - quando os dados que ele busca já estão na memória por meio de símbolos selecionados de uma definição de classe, então, obviamente, essa é uma abordagem muito ineficiente!

se você criou outra página de problema para expor suas reclamações a eles

Verdade seja dita, já fiz isso aqui:
https://visualstudio.uservoice.com/forums/121579-visual-studio/suggestions/9347001-improve-reboot-visual-studio-project-system

:)

@SamuelEnglard @aolszowka Este tópico começou em https://github.com/dotnet/roslyn/issues/11235 , que era sobre como melhorar o formato de definição do projeto. Para seu ponto, o que eu gostaria é um formato de projeto declarativo em vez de prescritivo. O MSBuild é, por necessidade, prescritivo. 90% do tempo, não me importo como isso faz, porque só quero dizer: "Ei .Net, está vendo todos esses arquivos? Você pode compilá-los todos em um assembly e depois empacotá-lo para todos esses destinos? Aqui estão todos os detalhes de como nomeá-lo e a versão. "

Para mim, a questão é: a ferramenta que obtém uma descrição declarativa de um projeto e produz a saída solicitada deve fazer parte do MSBuild ou de alguma outra coisa? Mas eu sinto fortemente que ele precisa ser padrão em todo o .Net (ou seja, um formato de arquivo no Windows, Linux, OS X se você estiver usando a linha de comando ou Visual Studio).

@ colin-young Você pode colocar seu número de versão em um arquivo MSBuild e ter seu AssemblyInfo.cs (ou parte dele) gerado por uma tarefa MSBuild. Eu fiz isso para meus projetos de trabalho, porque temos cerca de 100 projetos que queremos construir com a mesma versão. Agora, só temos um lugar para manter esse número de versão. Essa mesma propriedade de versão pode ser inserida na tarefa que cria os pacotes nuget.

CommonAssemblyInfo.targets:

<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003"> <PropertyGroup> <Year>$([System.DateTime]::Now.Year)</Year> <Version>1.2.3</Version> <Company>FooBar Technologies</Company> <Copyright>© $(Year) $(Company)</Copyright> <CommonAssemblyInfoFileName>CommonAssemblyInfo.cs</CommonAssemblyInfoFileName> </PropertyGroup> <ItemGroup> <Compile Include="$(CommonAssemblyInfoFileName)"/> </ItemGroup> <Target Name="CleanCommonAssemblyInfo" BeforeTargets="Clean"> <Delete Files="$(CommonAssemblyInfoFileName)" Condition="Exists('$(CommonAssemblyInfoFileName)')"/> </Target> <Target Name="CreateCommonAssemblyInfo" BeforeTargets="CoreCompile"> <ItemGroup> <AssemblyAttributes Include="AssemblyVersion"> <_Parameter1>$(Version).0</_Parameter1> </AssemblyAttributes> <AssemblyAttributes Include="AssemblyInformationalVersion"> <_Parameter1>$(Version).0</_Parameter1> </AssemblyAttributes> <AssemblyAttributes Include="AssemblyFileVersion"> <_Parameter1>$(Version).$(BuildNumber)</_Parameter1> </AssemblyAttributes> <AssemblyAttributes Include="AssemblyCompany"> <_Parameter1>$(Company)</_Parameter1> </AssemblyAttributes> <AssemblyAttributes Include="AssemblyCopyright"> <_Parameter1>$(Copyright)</_Parameter1> </AssemblyAttributes> </ItemGroup> <WriteCodeFragment Language="C#" OutputFile="$(CommonAssemblyInfoFileName)" AssemblyAttributes="@(AssemblyAttributes)" /> </Target></Project>

Basta importar este arquivo de destino para seu arquivo .csproj. (Pode ser necessário alguns ajustes, eu limpei este do que usamos. Dessa forma, você também não precisa se lembrar de atualizar o ano dos direitos autorais cada vez que a Terra gira em torno do sol.

@ colin-young @MarkPflug Excelente; você pode obviamente encadear isso a qualquer tarefa de que precisar; incluindo a embalagem do pacote NuGet e empurrando conforme necessário.

"Ei .Net, vê todos esses arquivos? Você pode compilá-los todos em um assembly e, em seguida, empacotá-lo para todos esses destinos? Aqui estão todos os detalhes de como nomeá-lo e a versão."

Não tenho certeza do que estou perdendo aqui; é exatamente assim que o msbuild pode funcionar; o que você tentou?

@ Mike-EEE

O que você ganha é uma sensação de descoberta e acesso - não apenas para os itens padrão descritos pelo xsd, mas qualquer objeto definido no arquivo.

Mais uma vez, não tenho certeza do que você ganha com isso; 75-80% do conteúdo em uma tarefa do MSBuild é simplesmente conectar corretamente a ferramenta subjacente ao MSBuild e seu sistema de registro. Você mesmo pode validar isso navegando na fonte ou refletindo sobre os binários com seu descompilador IL de escolha. Você verá que a maioria se estende da classe abstrata ToolTask helper para realizar a maior parte do trabalho sujo.

Você não obtém nenhuma visão adicional de como o ferramental deve ser usado além dos detalhes de implementação que não devem ser considerados.

Garanto que passei muito tempo no Visual Studio em muitos projetos, alguns dos quais utilizam bastante o WPF; mas ainda estou faltando onde você acha que isso é diferente do que é fornecido atualmente (mas devo admitir que precisa ser muito melhor desenvolvido).

Você pode fornecer um recurso mostrando que os XSDs são usados ​​para o intellisense? Esta é a primeira vez que ouço isso.

Este é o primeiro resultado do Google para "Intellisense xsd"; ele fornece uma visão geral de alto nível muito boa https://msdn.microsoft.com/en-us/library/ms255811.aspx se houver algo mais que você precise, me avise. A documentação afirma que só remonta ao VS 2005; que parece funcionar quando comecei a usar o VS.

E se um processo está criando "mais um arquivo" - mesmo na memória - quando os dados que ele busca já estão na memória por meio de símbolos selecionados de uma definição de classe, então, obviamente, essa é uma abordagem muito ineficiente!

Como você acha que o Intellisense está sendo fornecido a você agora? Não tenho certeza se você entende o que está argumentando aqui, ou talvez eu esteja completamente errado quanto ao motivo de você achar que isso é um problema. Você percebe que, para reunir a documentação do XML Doc Comments, o Visual Studio está criando uma estrutura (que pode até ser gravada em um arquivo XML) que contém a documentação de cada função, certo?

Tudo isso não vem ao caso; Recomendo fortemente que você dedique um tempo para entender como o Intellisense funciona antes de continuar esta discussão; começando aqui https://msdn.microsoft.com/en-us/library/hcw1s69b.aspx , aqui https://msdn.microsoft.com/en-us/library/s0we08bk.aspx , e aqui https: // msdn .microsoft.com / en-us / library / microsoft.visualstudio.language.intellisense.icompletionsourceprovider.aspx

Obrigado pelo link de voz do usuário; Vou direcionar informações adicionais conforme necessário.

@aolszowka LOL Acho que definitivamente estamos tendo nossas definições cruzadas aqui (e não me interpretem mal, eu realmente aprecio seu diálogo!). Eu entendo como o Intellisense funciona de um ponto de vista funcional, mas de um ponto de vista _técnico_, não vejo nenhuma evidência de que o Intellisense dependa (ou confie em) um xsd para operar. O artigo que você me mostrou explica como o intellisense opera em um XSD, mas não diz que _requer um xsd_ para funcionar. Isso faz sentido? Grande diferença. :sorriso:

Mais uma vez, não tenho certeza do que você ganha com isso; 75-80% do conteúdo em uma Tarefa MSBuild é simplesmente conectar corretamente a ferramenta subjacente ao MSBuild e seu sistema de registro

Certo, e as ferramentas que fornecem isso não são tão eficazes quanto dizer o que você vê em um contexto baseado em Xaml. Talvez seja uma questão de abordagem, mas ao aprender uma nova API, eu e os desenvolvedores que conheço passamos muito tempo navegando por objetos / classes para aprender o sistema. A documentação é realmente um segundo pensamento e raramente usada. Na verdade, as palavras atrapalham a linguagem real, o código! :)

Você não obtém nenhuma visão adicional de como o ferramental deve ser usado além dos detalhes de implementação que não devem ser considerados

Caramba, esta é uma visão muito estreita (beirando a mente fechada!)! Esse pode ser o caso de realmente juntar uma tarefa e um senso "apenas faça e nunca pense sobre isso novamente", mas os desenvolvedores (novamente, os bons que eu conheço) gostam de explorar. Quando você impede esse processo (ou o torna difícil), isso fornece uma experiência ruim. A experiência ruim do desenvolvedor resulta em uma adoção ruim e, pior ainda, em um sentimento ruim em relação ao seu produto.

É por isso que os desenvolvedores Xaml são realmente apaixonados por seu Xaml, por causa da _experiência_ que ele oferece, e isso é parte do objetivo aqui - melhorar a experiência do desenvolvedor neste formato e modelo.

Não vejo nenhuma evidência de que o intellisense dependa (ou confie em) um xsd para operar. O artigo que você me mostrou explica como o intellisense opera em um XSD, mas não diz que requer um xsd para funcionar.

Na verdade, sim; logo abaixo do primeiro cabeçalho:

"Depois que um esquema é associado ao seu documento, você obtém uma lista suspensa de elementos esperados sempre que digitar" <"ou clicar no botão Exibir uma Lista de Membros de Objeto na barra de ferramentas do editor XML. Para obter informações sobre como associar esquemas a seus documentos XML, consulte Validação de documento XML. "

Por favor, entenda que neste contexto o esquema é um XSD (Documento de Esquema XML).

Além disso, a leitura do link in-lined (consulte Validação de Documento XML) afirma claramente:

"O Editor de XML verifica a sintaxe do XML 1.0 e também realiza a validação de dados conforme você digita. O editor pode validar usando uma definição de tipo de documento (DTD) ou um esquema. Sublinhados ondulados em vermelho destacam quaisquer erros bem formados de XML 1.0. Sublinhados ondulados em azul mostram semântica erros com base em DTD ou validação de esquema. Cada erro tem uma entrada associada na lista de erros. Você também pode ver a mensagem de erro pausando o mouse sobre o sublinhado ondulado. "

E ainda mais:

"Ao editar um arquivo XML Schema, o arquivo xsdschema.xsd localizado no cache do esquema é usado para validação. Os erros de validação são mostrados como sublinhados ondulados em azul. Quaisquer erros de compilação também são mostrados com sublinhados ondulados em vermelho."

Em um arquivo MSBuild, isso é carregado implicitamente pelo comando de namespace:

xmlns="http://schemas.microsoft.com/developer/msbuild/2003"

Exatamente da mesma forma que seria carregado para qualquer Xaml ou outro formato de documento baseado em XML. Isso não é exclusivo para nenhum desses formatos de arquivo, mas faz parte do padrão de documento XML bem definido.

O artigo que você me mostrou explica como o intellisense opera em um XSD, mas não diz que requer um xsd para funcionar. Isso faz sentido? Grande diferença.

Essa é uma distinção sem diferença; no entanto, não vem ao caso.

Certo, e as ferramentas que fornecem isso não são tão eficazes quanto dizer o que você vê em um contexto baseado em Xaml.

Não tenho certeza do que você está dizendo aqui; Não tenho certeza de como olhar para a fonte de uma tarefa (por exemplo https://github.com/Microsoft/msbuild/blob/c1459f5cbd36f2c33eafc8f4ff087f6ee84c3640/src/XMakeTasks/Move.cs) dá a você alguma ideia sobre como a tarefa (Mover ) deve ser usado dentro do MSBuild; não há nenhum requisito (embora seja uma boa prática) que um comentário de uso seja associado ao código que define a tarefa.

Digamos por um momento que eles implementaram o que você descreveu; Quando você foi destacado em um nome de tarefa, ao pressionar F12 (Ir para a definição), você foi para a fonte de referência ou para uma versão descompilada do assembly referenciado no momento. Qual seria a aparência do seu fluxo de trabalho se você estivesse tentando usar a tarefa (não depurar a tarefa)?

Caramba, esta é uma visão muito estreita (beirando a mente fechada!)!

Esta é uma visão comumente compartilhada pelos consumidores de qualquer API; entender como a chamada de API é implementada pode servir a algum desejo de entender como as coisas funcionam; mas não explicará como deve ser integrado com outras partes da API para realizar tarefas úteis, nem qual é a expectativa da pessoa que fornece a API.

Você precisa saber como File.Delete(string) é implementado? Como isso mudaria a forma como você utiliza a função além do que foi documentado para ela? E quanto a interfaces ou arquivos de cabeçalho; que não fornecem detalhes de implementação (como é seu propósito).

Quando você impede esse processo (ou o torna difícil), isso fornece uma experiência ruim.

Para um "Bom Desenvolvedor", isso nunca foi um impedimento; mesmo antes do código aberto deste projeto. A Microsoft não ofusca seu código; você sempre poderia ter olhado "sob o capô" para a implementação de qualquer uma das classes fornecidas usando qualquer número de descompiladores IL disponíveis.

No entanto, como afirmei antes, não há nada a ser obtido da visualização do código-fonte da Tarefa MSBuild que não tenha sido melhor abordado na documentação que, no final das contas, é a garantia da Microsoft.

Bons desenvolvedores também reconhecem em qual camada de abstração concentrar seu tempo de pesquisa. Bons proprietários de produtos sabem onde investir tempo em recursos e como obter o que é solicitado. Bons escritores de documentos produzem documentação suficiente de forma que rastejar na fonte deve ser desnecessário.

@aolszowka nunca em um ambiente profissional, por alguém que eu consideraria um desenvolvedor profissional (ou Build Master), diria que ouvi um pedido de mudança para um MSBuild baseado em JSON.

Oi. Sou um desenvolvedor profissional. Fui desenvolvedor líder em vários projetos importantes em uma das 20 principais bolsas de valores. Eu era o principal arquiteto de soluções. Eu conhecia o MSBuild / Team Build melhor do que a maioria dos Build Masters de lá e os ajudei a desenvolver e depurar seus builds. Eu admito, não quero um MSBuild baseado em JSON. Quero que o MSBuild acabe. Seria bom se sua substituição mais simples fosse um formato mais fácil do que XML para humanos.

@aolszowka Eu sei que a comunidade teve um influxo recente de posers do movimento "DevOps"; mas ainda existem poucos que realmente sabem o que estão fazendo além de uma interface drag n 'derp.

Estou no campo DevOps, sim. Aumentei o ritmo de entrega do meu cliente atual em mais de 100% em um ano (com menos equipe), adotando técnicas de DevOps. Você sabe, entregando mais valor ao negócio em menos tempo. Isso é o que os engenheiros de software "profissionais" fazem. Oh espere, eu sou um "poser". E não sei o que estou fazendo se não tiver uma interface de arrastar e soltar. Hmm, onde está esse IDE? Sim, não tenho um instalado. Difícil de arrastar e soltar em um editor de texto.

@aolszowka Leitura de Sayed Ibrahim Hashimi "Por dentro do Microsoft Build Engine: Usando o MSBuild e o Team Foundation Build" também deve ser leitura obrigatória para qualquer pessoa que afirma ter conhecimento íntimo.

Leia-o. De capa a capa. Mais de uma vez. Anos e anos atrás. E ainda rejeitei o MSBuild. Então, espere, pela sua definição eu tenho um conhecimento íntimo. Como posso não gostar do MSBuild? Esperando ansiosamente pela resposta "bem, você obviamente não entendeu" ...

@aolszowka Olhando para project.json (eu nunca tinha ouvido falar desse projeto até hoje)

Uau. Você está descartando os pontos de vista dos outros a torto e a direito, denegrindo suas habilidades e fazendo comentários maliciosos sobre eles serem posers, mas não sabe qual é a maior mudança programada para a cadeia de ferramentas do .NET Core? Bem, até ontem, isto é ...

@aolszowka Se você está tentando atingir um público que não está usando o Visual Studio, então eles devem ser encorajados a procurar o sistema de projeto recomendado de escolha para seu ambiente.

Sim eu fiz. Era chamado de project.json. O ambiente era .NET Core no OSX. Mas agora eles estão me forçando a usar o MSBuild, e eu não quero, porque é uma porcaria de IMO.

@aolszowka O JSON Kids ainda não cresceu o suficiente para entender por que tais sistemas são necessários; parece que eles estão começando a mudar com base em uma rápida pesquisa no Google.

"Crianças", hein? Não cresceu o suficiente? Puxa, se você está me chamando de criança, adoraria ouvir sobre sua experiência profissional.

Alguns desenvolvedores consultam seu ambiente de tempos em tempos e avaliam alternativas. Eles experimentam Python, ou Java, ou Maven, ou Scala, ou F #, ou Fake, ou SBT, ou TypeScript. E eles _aprendem_. E eles melhoram. E eles julgam suas principais ferramentas de ambiente de desenvolvimento com base no que viram agregando valor em outros lugares.

Outros desenvolvedores se concentram em um conjunto de ferramentas e uma pilha para toda a carreira e nunca aprendem nada fora de seu âmbito. Eles acham que suas principais / únicas ferramentas de desenvolvimento são o One True Way ™ e não há por que olhar para outra coisa.

Apenas um conselho amigável de carreira: descobri que o segundo conjunto de desenvolvedores são sempre aqueles que são dispensados ​​primeiro e que nunca alcançam o potencial de ganho do primeiro conjunto de desenvolvedores. Mas hey, essa é apenas minha experiência depois de duas décadas de anos no campo, apenas um garoto poser.

Na verdade, aqui está uma captura de tela do meu leitor Kindle online:

@shederman

O que o levou a rejeitar o MSBuild para seus fluxos de trabalho e como você acha que a mudança sugerida irá melhorar o MSBuild de forma que você o reavalie no futuro?

Cara, era só dor. _Eu_ poderia fazer funcionar, mas poucos desenvolvedores gastaram tempo ou se importaram. Então, se eu configurei algo em um projeto, eles não transferiram para outro. Se houvesse um problema, eu teria que consertá-lo. Mesmo aqueles Build Masters não tinham noção de muitas das coisas. Pelo que pude ver, eles não estavam em sua liga de maneira alguma, sou um cara ocupado, não tenho tempo para perseguir problemas de construção.

Eu só quero algo que seja facilmente editado pelos desenvolvedores, apresentado de uma maneira familiar e intuitiva, e não requeira conhecimento interno complexo. E eu entendo grupos de propriedades, mas para desenvolvedores baseados em imperativos eles são contra-intuitivos e uma incompatibilidade de impedância.

O MSBuild usa um sistema de inferência para determinar o que fará e como fará. project.json usou um sistema declarativo para descrever propriedades e dependências. Ele não tentou dizer o que deveria ser feito, isso cabia ao conjunto de ferramentas, que _sabia_ como construir coisas.

Isso é suficiente para um sistema de compilação completo? Não, não é. Mas é suficiente para arquiteturas baseadas em microsserviços em muitos casos. Temos serviços pequenos e simples, com requisitos de construção simples. Por que precisamos desse sistema de inferência para descrever o que é extremamente óbvio? Restaure pacotes, construa, teste, empacote.

Nas poucas ocasiões em que precisei de sequências de algo, um arquivo de script Powershell ou Bash funcionou perfeitamente. Novamente, não é algo complexo. Não estamos construindo um sistema operacional. A complexidade está nos sistemas de implantação e gerenciamento, não na construção.

Então, com certeza, precisaremos de algum tipo de sistema de execução de tarefas em algum momento. Mas isso realmente tem que ser baseado em inferências? A solução de goles baseada em fluxo é muito intrigante. Talvez não seja viável para .NET, mas uma indicação de como você pode ter um sistema baseado em tarefas com lógica de tipo imperativo.

@shederman

Então, se eu configurei algo em um projeto, eles não transferiram para outro.

Há um motivo pelo qual a inclusão ou a predefinição de projetos comuns usando os modelos do Visual Studio não atendem a essa necessidade?

não requer conhecimento interno complexo

O diabo está sempre nos detalhes; há um equilíbrio que precisa ser alcançado entre flexibilidade, complexidade e facilidade de uso para desenvolvedores que não estão focados em tais tarefas, eu concordo. No entanto, achei que o MSBuild encontrou um meio razoável no que diz respeito aos requisitos colocados nele.

O MSBuild usa um sistema de inferência para determinar o que fará e como fará. project.json usou um sistema declarativo para descrever propriedades e dependências. Ele não tentou dizer o que deveria ser feito, isso cabia ao conjunto de ferramentas, que sabia como construir coisas.

Talvez, como você disse, "nunca aprendi nada fora do âmbito deles", mas estou confuso quanto ao que você espera que o sistema faça aqui; em algum momento você precisa declarar suas dependências. Você poderia dar um exemplo disso?

Por que precisamos desse sistema de inferência para descrever o que é extremamente óbvio?

Porque este sistema é usado para mais do que simples microsserviços; Ele é usado para construir tudo, desde um aplicativo Hello World a sistemas complexos de várias camadas com várias dependências e requisitos de construção. A extensibilidade fornecida pelo MSBuild atinge o melhor equilíbrio possível para atender às necessidades concorrentes.

Nas poucas ocasiões em que precisei de sequências de algo, um arquivo de script Powershell ou Bash funcionou perfeitamente.

Isso requer que essas ferramentas adicionais sejam enviadas junto com o sistema de compilação proposto; com o MSBuild, eles podem ser incorporados ao próprio sistema. Se o seu objetivo final é reduzir a quantidade de configuração que um desenvolvedor final está fazendo, exigindo que o Powershell ou o Bash sejam configurados corretamente no sistema é simplesmente outro obstáculo (facilmente automatizado).

Não vi uma resposta para a última parte da pergunta; que foi _como esta sugestão melhora o MSBuild para que você o reavalie para seus propósitos? _

Não estou aqui para bater o tambor e dizer que o MSBuild atende a todas as necessidades; está longe de ser uma solução perfeita para todos os usuários finais. No entanto, estou aqui para bater o tambor contra a tentativa de modificá-lo em algo que ele não é; e não pode ser sem um investimento significativo que resulta em um redesenho fundamental do produto.

Em algum ponto, é melhor abandonar esse produto e passar para outro que seja mais adequado para atender às necessidades de seus desenvolvedores.

Há um motivo pelo qual a inclusão ou a predefinição de projetos comuns usando os modelos do Visual Studio não atendem a essa necessidade?

Eu usei inclusões comuns para mim, mas sempre as achei uma dor também. Você não costuma instalá-los / atualizá-los, então eles tendem a não estar nas novas compilações de máquina. Causa alguma hilaridade quando os desenvolvedores não podem construir e estão lutando para descobrir o porquê, quando um arquivo mágico é necessário para que funcione.

Eu criei VS Templates algumas vezes, mas achei um pouco uma perda de tempo. Os modelos tendem a exigir muita manutenção que não compensa.

Eu acho que ambas as soluções _funcionariam_ em um mundo onde eu tivesse uma equipe de Build Masters capazes fazendo essas coisas por mim. Eu tive Build Masters em apenas um cliente até agora, e seria um exagero chamá-los de capazes.

Achei que o MSBuild encontrou um meio razoável no que diz respeito aos requisitos colocados nele

Cara, é por isso que estou me envolvendo com você. Não estou tentando convencê-lo de que o MSBuild é horrível, só quero que você perceba que muitas equipes de desenvolvimento profissionais e capazes o consideram abaixo do ideal para suas necessidades. O meio que atravessa não se aproxima muito de suas necessidades.

A extensibilidade fornecida pelo MSBuild atinge o melhor equilíbrio possível para atender às necessidades concorrentes

Certo. Então é um spork. Eu quero um garfo. Outros querem uma colher. Mas não é nenhum dos dois. Às vezes, você tem que ser opinativo e, às vezes, precisa perceber que atender a todas as necessidades não é possível nem econômico. Além disso, a maioria das minhas reclamações está relacionada à _forma_ da extensibilidade que ele implementou. Existem outras maneiras de fazer isso.

Se o seu objetivo final é reduzir a quantidade de configuração que um desenvolvedor final está fazendo, exigindo que o Powershell ou o Bash sejam configurados corretamente no sistema

Hum, brew e chocolatey . Instalar essas ferramentas é mais rápido e fácil do que editar um arquivo msbuild. Eles são imperativos, então os desenvolvedores os grocam facilmente, sem uma incompatibilidade de impedância. Eles são perfeitos? Não. Um sistema de construção adequado seria melhor? Pode ser. O MSBuild seria melhor? Não na minha opinião, não nos meus casos de uso.

como essa sugestão melhora o MSBuild para que você o reavalie para seus propósitos?

Não estou _tentando_ para melhorar o MSBuild. Não quero modificá-lo para algo que não é.

Eu quero isso totalmente fora da minha cadeia de ferramentas.

Em algum ponto, é melhor abandonar esse produto e passar para outro que seja mais adequado para atender às necessidades de seus desenvolvedores

Concordo totalmente! Mas estava feito, era project.json. E então a MS decidiu desistir dessa decisão e voltar para o MSBuild.

Acho que estamos confundindo um tópico de problemas com muita argumentação filosófica :-)

Me mande um e-mail para continuar a conversa.

Não tenho certeza do que você está dizendo aqui;

Eu acho que resume esta conversa para apontar perfeitamente. :sorriso:

Na verdade, sim; logo abaixo do primeiro cabeçalho:

LOL ... Agradeço linha por linha do artigo que você me pediu para ler (e eu li, bem, dei uma olhada porque já sei a maior parte. :)). Estamos definitivamente confusos aqui. Você está dizendo que o Intellisense usa XSDs para trabalhar em um XML, o que é preciso, mas não em todos os casos. Em minha mente, também estava pensando em arquivos Xaml. O Intellisense funciona perfeitamente sem um XSD. Porque? Por causa da definição da classe. Neste caso (e eu diria que deveria ser para todos os casos) _a definição de classe é o esquema_. Fiquei com a impressão de que você estava dizendo que o XSD foi gerado automaticamente em tais casos, que é onde eu estava pedindo a referência.

você poderia sempre ter olhado "sob o capô" para a implementação de qualquer uma das classes fornecidas usando qualquer número de descompiladores IL disponíveis

Certo, e qual é a quantidade de esforço necessária para fazer isso? Eu tenho que encontrar um compilador e aprender como ele funciona, então navegar até o arquivo e começar a discutir a partir daí. Converta isso com a experiência de pressionar CTRL-B (via ReSharper - talvez F12 também funcione atualmente?) Em qualquer símbolo em um arquivo Xaml e ser levado diretamente para a definição (descompilada). Aqui, o ferramental está trabalhando com você, não contra você.

Você precisa saber como File.Delete (string) é implementado?

Sim, se eu puder. Ver como ele é implementado me dá conhecimento como desenvolvedor e melhora minhas habilidades, bem como me dá acesso e visibilidade de como outros desenvolvedores usando .NET (e no exemplo você forneceu um que trabalha diretamente para MSFT!) Resolvem problemas . Ter acesso a esse conhecimento, em última análise, melhora meu conjunto de habilidades como desenvolvedor e, novamente, separa os desenvolvedores "bons" (experientes / artesãos) daqueles que "apenas querem fazer o trabalho e passar para a próxima coisa pela qual alguém está me pagando. "

Tudo isso novamente leva à experiência do desenvolvedor. A experiência que leva a mais conhecimento / visibilidade com o mínimo de trabalho / atrito é aquela que os desenvolvedores gravitarão e adotarão.

Qual seria a aparência do seu fluxo de trabalho se você estivesse tentando usar a tarefa (não depurar a tarefa)?

Agora estamos a falar. Não há um fluxo de trabalho em si, mas mais um acesso de ferramentas às informações que eu necessito (ou simplesmente estou interessado). O objetivo é reduzir a confusão e melhorar a acessibilidade e o conhecimento do desenvolvedor com uma determinada biblioteca e / ou API. O desenvolvimento de Xaml é o melhor que posso pensar, é por isso que sempre me refiro a ele, mas estou realmente aberto a qualquer sistema que forneça suas qualidades.

@shederman

Eu usei inclusões comuns para mim, mas sempre as achei uma dor também. Você não costuma instalá-los / atualizá-los, então eles tendem a não estar nas novas compilações de máquina.

Existe um motivo pelo qual os métodos de implantação, como o NuGet, não foram usados ​​para mantê-los atualizados (você também mencionou o chocolate e a cerveja, que também podem fazer isso)? Ou uma etapa ainda mais fácil de verificá-los na raiz do projeto para que sejam atualizados ao mesmo tempo que seus desenvolvedores usam o controle de versão para obter as alterações?

Esse é o único ponto de dor que você encontrou?

Eu criei VS Templates algumas vezes, mas achei um pouco uma perda de tempo. Os modelos tendem a exigir muita manutenção que não compensa.

Acho que não encontrei mais trabalho para eles do que editar o arquivo MSBuild para o seu projeto; novamente com várias ferramentas de gerenciamento de implantação / ambiente, ele permite que você os atualize rapidamente para o padrão que você precisa que seus desenvolvedores usem.

Eu tive Build Masters em apenas um cliente até agora, e seria um exagero chamá-los de capazes.

Você por acaso iria tão longe para chamá-los de crianças poser?

Cara, é por isso que estou me envolvendo com você. Não estou tentando convencê-lo de que o MSBuild é horrível, só quero que você perceba que muitas equipes de desenvolvimento profissionais e capazes o consideram abaixo do ideal para suas necessidades. O meio que atravessa não se aproxima muito de suas necessidades.

E o motivo pelo qual estou interagindo com você é, aparentemente, que estou no grupo de desenvolvedores que gosta de entender os problemas que outros desenvolvedores enfrentaram (ou seja, as limitações das ferramentas); entender qual foi a solução deles para o problema; e, em seguida, descobrir como resolveria uma classe semelhante de problema, caso encontrasse no meu trabalho ou quando alguém postar uma pergunta semelhante no StackOverflow.

Além disso, a maioria das minhas reclamações está relacionada à maneira como a extensibilidade foi implementada. Existem outras maneiras de fazer isso.

Eu gostaria de entender isso; quais lutas você encontrou.

Hum, cerveja e chocolate. Instalar essas ferramentas é mais rápido e fácil do que editar um arquivo msbuild.

Com certeza é bom quando você corta a poção daquele comentário que menciona (facilmente automatizável). Por essa lógica, as soluções acima deveriam ser mais fáceis de implantar; você, entretanto, disse que era uma dor porque você não abre os desenvolvedores de instalação / atualização?

Não estou tentando melhorar o MSBuild. Não quero modificá-lo para algo que não é.

No entanto, você está aqui; sobre este assunto em particular?

Me mande um e-mail para continuar a conversa.

Visto que você não deixou seu endereço de e-mail, sinta-se à vontade para entrar em contato primeiro, seu nome de usuário git em um serviço de e-mail popular do Google.

@SamuelEnglard

Acredito que você quisesse mencionar @shederman em vez de nosso estimado @SamuelEnglard. Ou eu apenas entrei de novo? :sorriso:

(excelentes perguntas!)

@ Mike-EEE

Em minha mente, também estava pensando em arquivos Xaml. O Intellisense funciona perfeitamente sem um XSD. Porque?

Porque, como afirmei em minha postagem acima, seu arquivo Xaml está incluindo os xmlns e o Visual Studio está executando essa tarefa necessária para você; além disso, também executa várias técnicas de extração de documentos XML para reunir as informações de que precisa.

Certo, e qual é a quantidade de esforço necessária para fazer isso?

Nenhum, você já está fazendo isso sozinho; você mesmo mencionou que usa o ReSharper; incluído nesse conjunto de ferramentas está o dotPeek, um dos muitos IL Decompilers disponíveis comercialmente. Isso é o que está ocorrendo quando você atinge Ctrl+B em seu ambiente. Outras dessas ferramentas seriam Reflector, IL Spy, JustDecompile e o bom e velho ILDASM.

ferramentas de acesso às informações de que necessito (ou nas quais estou simplesmente interessado)

O código-fonte dessa ferramenta agora está disponível abertamente (com comentários); O que você está pedindo basicamente equivale a uma melhoria para vinculá-lo diretamente à fonte de referência (algo feito em uma versão mais recente do Visual Studio, como 2015, ao navegar por fontes conhecidas, como o BCL).

Embora haja méritos em examinar o código, isso não ajuda alguém novo no MSBuild a entender o sistema; uma meta de design para seu sistema aprimorado proposto, se eu entendi tudo o que você disse aqui. Só não vejo como isso leva você até lá.

Concordo que tudo se parece com o problema XY.

@ Mike-EEE

Não, você estava certo, obrigado pela captura!

@aolszowka Meu endereço de e-mail está em meu perfil público do github ...

Você por acaso iria tão longe para chamá-los de crianças poser?

Eu não acredito que chamei alguém de tal coisa. Sempre.

Isso seria você.

Estou cansado de você continuamente tentar tornar pessoal esse argumento sobre ferramentas de software. Edite ou reenvie as perguntas ou envie-as para meu endereço de e-mail privado.

Porque, como afirmei na postagem acima, seu arquivo Xaml está incluindo os xmlns e o Visual Studio está realizando essa tarefa necessária para você

OK ... então aqui está o nosso problema. Não acredito que o XSD seja usado a qualquer momento durante uma resolução de esquema de arquivo Xaml. Mas, eu não estou 100% familiarizado com componentes internos da Intellisense e isso está saindo do escopo aqui e quero manter isso no tópico (eu realmente acabei de dizer isso ?!)

Isso é o que está ocorrendo quando você pressiona Ctrl + B em seu ambiente

Certo, mas isso NÃO acontece em um arquivo MSBuild. A propósito, se o MSBuild alternasse / suportasse um formato Xaml, tudo funcionaria conforme solicitado com muito pouco esforço. :sorriso:

Embora haja méritos em examinar o código, isso não ajuda alguém novo no MSBuild a entender o sistema; uma meta de design para seu sistema aprimorado proposto, se eu entendi tudo o que você disse aqui. Só não vejo como isso leva você até lá.

Haha ... parece um: -1: de @aolszowka aqui. Acho que fiz o meu melhor aqui para explicar minha posição para você. Parece que fiz um péssimo trabalho. Talvez alguma outra perspectiva / conversa me ajude a transmitir meu ponto de vista mais tarde. :oculos escuros:

Duas ideias aleatórias que eu gostaria de ver:

1. Importação trivial de adereços de outro formato. Muitas das coisas boas em torno do project.json eram a capacidade de editar a configuração de maneira trivial. Remover a sujeira e fazer algo como:

MyLibrary.csproj

<?xml version="1.0" encoding="utf-8"?><Project> <Import Project="project.json" Type="application/json "/> <Import Project="$(MSBuildToolsPath)\Microsoft.CSharp.targets" /></Project>

project.json :

{ "name": "MyLibrary"}

Com coisas como referências, <ItemGroup><Compile Include="**\*.cs" /></ItemGroup> , namespaces e outros incluídos por padrão. Project.json ditaria empacotamento, nomenclatura, inclui / exclui, dependências, enquanto csproj iria realmente colar tudo junto. Configuração fácil, legível e editável. Mais convenção sobre configuração. Todo mundo Muitas pessoas ganham.

1. Faça com que seja trivial desembolsar para algo como .csx ou outras ferramentas de script para uma extensão fácil. Goste ou não, a tarefa de escrever não é simples atualmente. FAKE , Cake e psake para projeto cruzado e orquestração de implantação, msbuild para colagem e configuração do projeto e capacidade de inserir scripts para estender o projeto builds, ao mesmo tempo em que minimiza a necessidade de interagir com o Xml, as pessoas parecem odiar muito.

Avise-me se algo parecer errado ou faltar alguma coisa. Sei que isso ainda é uma simplificação exagerada do que seria necessário. Muita inspiração de

Então, basicamente:

Vamos remover praticamente tudo sobre o MSBuild, exceto tornar o MSBuild o coordenador

Quero dizer, é um passo na direção certa. Mas por que eu preciso ou desejo o envolvimento do MSBuild então? Por que estou criando uma tecnologia legada antiga, que um grande número de desenvolvedores passou a odiar, a construir?

Qual é o caso de uso do MSBuild em tal cenário?

project.json está atuando essencialmente como o arquivo do projeto
project.json / nuget.json são as referências
Scripts para construções de projetos

O que o MSBuild faz exatamente?

Executamos dotnet build
Ele acelera o MSBuild
Que nada mais faz do que coordenar uma lista bem conhecida de etapas

Então, novamente, o que o MSBuild faz? E se faz tão pouco, por que o estamos usando?

Não, não, que tal isso:

1. Construir no sistema de projeto project.json
2. Ter o dotnet build capaz de restaurar, construir, testar e empacotar
3. Permitir que um ponto de extensão seja enviado ao MSBuild para as pessoas que o desejam
4. Também permite que o referido ponto de extensão seja aplicado a outros sistemas de construção

Essencialmente, temos um "processo básico" integrado às ferramentas, que pode ser estendido por compilações personalizadas, se necessário. A única desvantagem que vejo sobre isso é que provavelmente mantém comandos no arquivo project.json, que teoricamente deveria ser uma definição de projeto pura.

"build": "msbuild MyProject.csproj"; // Ta-daa!

OU , minha proposta original, tenho ambos. Se você tiver um projeto csproj entregue, construa-o usando o MSBuild e, se tiver um projeto project.json entregue, construa-o usando as ferramentas simples integradas.

E a sintaxe que sugeri há apenas uma opção.

Poderíamos, por exemplo, executar msbuild se houver um arquivo project.msbuild no diretório. Só precisa haver algo que diga ao sistema "padrão" para usar um sistema de construção "adequado".

Grande parte da causa raiz do envolvimento excessivo do MSBuild no sistema VS é que ele tenta fazer tudo. Faz referências e construção e definição de projeto? Porque? Porque é a raiz do sistema de compilação.

Não deveria ser. A raiz do sistema de construção deve construir uma definição de projeto bruta.

MSBuild deve ser uma _opção_ para aqueles que precisam de sua potência e extensibilidade.

O MSBuild deve ser uma opção para aqueles que precisam de poder e extensibilidade.

Estou gostando muito dessa abordagem! No mínimo, precisamos ter mais de uma solução baseada em opções, onde você escolhe seu próprio construtor. Temos isso para quase todo o resto na cadeia de ferramentas CI / CD ... mas build é algo que se supõe ser uma tecnologia específica, exatamente como você descreve aqui .

Também cavando a sugestão de @ RichiCoder1 :

Torne trivial desembolsar para algo como .csx ou outras ferramentas de script para facilitar a extensão

Isso é PowerShell? Definitivamente, é necessário haver uma melhor integração com isso também. (e também, o PowerShell deve ser mais parecido com C # , mas isso é outra discussão. #shamelessplug: hung_out_tongue:).

"Tecnologia de legado antigo", como o msbuild, geralmente é bem testada, cobre muitos casos dos quais você felizmente não tem conhecimento (cenários minuciosamente testados em batalha), tem boa integração com muitos outros componentes e ferramentas.

Em um mundo onde o .NET é realmente uma plataforma universal: todos os dispositivos, todos os tipos de aplicativos, você precisa do msbuild.

Aqui estão algumas "tecnologias antigas e legadas" tão antigas ou mais antigas que o msbuild com as quais você deve estar familiarizado: UNIX, Linux (dá poder ao mundo), C (outro), C ++ (outro), C #, Visual Studio, Mac OS.

Como aqueles, o msbuild não parou de evoluir.

Como aqueles, o msbuild não parou de evoluir.

Instrução mais fácil de aceitar se fosse possível escrever definições do MSBuild em JSON. :sorriso:

Ninguém duvida de seu poder e capacidade. Estou de acordo que o MSBuild deve seguir em frente (

Sim, sim, eu sei que é uma missão tola correr atrás do último brinquedo brilhante, mas os _melhores_ aspectos que tornam esses brinquedos atraentes devem, pelo menos, influenciar um bom produto de alguma forma. Acho que a evolução adequada explica isso, sendo C # provavelmente o melhor exemplo.

Ninguém está dizendo que devemos descontinuar o MSBuild. Ninguém está dizendo que o MSBuild não tem futuro.

Tudo o que estamos dizendo é que agora, existem dois sistemas de compilação, gostamos do "novo" sistema de compilação e queremos mantê-lo. Estamos dizendo que o MSBuild não funciona bem para muitos de nossos cenários mais simples. Portanto, vamos manter a "construção simples" junto com o suporte do MSBuild. Por que tirar a escolha? Por que forçar um sistema de compilação complexo e contra-intuitivo em pessoas que desejam apenas compilar as coisas no diretório? Se quisermos executar um sistema de compilação complexo não MSBuild, por que nos forçar a executá-lo _por_ MSBuild também? Quer dizer, isso é ridículo.

Estou até me oferecendo para fazer o trabalho. Coloque a boca ou cale a boca, certo? Farei o que a refatoração for necessária para manter o "novo" sistema de compilação trabalhando lado a lado com o antigo. Contanto que você não torne isso impossível para mim, é claro 😉.

E é fácil dizer que o MSBuild está evoluindo, mas vi mais ofertas de "evolução" do MSBuild na semana passada do que nos últimos 5 anos! Porque? Porque há perspectiva de competição. Mas mesmo uma evolução significativa não mudará o fato de que é realmente mais ideal para mestres de compilação dedicados que executam grandes pipelines de CI e compilações complexas. Nem todos nós temos isso hoje em dia. Nem mesmo em muitas das empresas. Temos compilações simples, pipelines de CI simples e implantações complexas. Temos a tendência de tratar nossas construções como gado, não como animais de estimação - apenas como nossos servidores.

Pessoalmente, acredito que um dos pontos de venda do .NET Core e do ASP.NET vNext foi atrair uma nova geração de desenvolvedores para a plataforma, para ajudar a conter o lento declínio na adoção do .NET. É remover um dos pontos de venda do .NET Core, uma das principais promessas - e voltar para um sistema desprezado por uma grande fração de sua comunidade (especialmente aqueles que trabalham no lado da programação onde a nova geração corta seus dentes) realmente vai ajudar?

Esta foi uma má decisão da IMO e feita sem considerar todos os seus usuários ou suas opiniões, então, por favor, pare de se preocupar com isso. Admita, procure alternativas que permitam uma solução lado a lado e siga em frente.

Soluções já foram oferecidas para uma experiência tranquila lado a lado.

Dizer que o MSBuild será brilhante e novo apenas porque (digamos) agora pode usar JSON é tão ingênuo. project.json pode parecer simples para coisas simples, como definir dependências, tempos de execução e outras coisas. Se você fez algum trabalho de construção sério, sabe que isso cobre cerca de 10% do que você pode fazer com o MSBuild. E, se você precisar fazer isso, tenho certeza de que a experiência de edição JSON será ainda pior do que XML (a partir do "suporte" de hoje no VS para edição também).

Agora, se você estava propondo yaml ....;).

Eu acho que há maneiras de tornar o MSBuild mais acessível (melhor intellisense, melhor fatoração / divisão de um .csproj para ajustes mais fáceis -.props / .targets junto com .csproj por padrão), mas seus conceitos e recursos principais não são tão complicados alcançar.

Seu poder e flexibilidade são evidentes apenas quando você vai além de "é um coordenador simples", que é o que project.json pode sugerir é tudo o que há para uma construção complicada.

Agora, se você estava propondo yaml ....;).

Bem, sim ... sugerindo isso e muito mais , na verdade. :sorriso:

Direi que acho que prestamos um péssimo serviço ao MSBuild e ao problema em questão, trazendo formatos, ou melhor, descrevendo o problema usando / comparando formatos. É uma pena que o sistema de compilação do .NET Core oferece suporte apenas a JSON e o MSBuild oferece suporte apenas a XML. No final das contas, esses formatos estão (ou deveriam ser) representando modelos serializados que são desserializados na memória em algum ponto para serem executados pelo sistema. Mas como esses sistemas suportam apenas um determinado formato, isso complica o problema, pois os desenvolvedores o transformam em uma batalha religiosa sobre quem tem o formato superior (não importa a tecnologia!). Além disso, o formato bloqueado tende a servir como um pára-raios para a experiência geral do usuário / desenvolvedor e associação de produto - para melhor ou para pior.

Seu poder e flexibilidade são evidentes apenas quando você vai além de "é um coordenador simples", que é o que project.json pode sugerir é tudo o que há para uma construção complicada.

Você meio que tocou nisso, mas uma coisa que está ficando aparente para mim é que definitivamente há uma separação conceitual entre _definição de projeto_ (em que a compilação do .NET Core é "boa") e _definição de processo_ (o que é MSBuild " bom em). Ter uma melhor separação logística de arquivos (como você sugere!) No formato que os desenvolvedores preferem ajudaria muito, eu acho.

(Aliás, agradeço os pesos pesados ​​que vieram para agraciar este tópico com seus pensamentos. @migueldeicaza suas opiniões são _sempre_ bem-vindas! Obrigado por reservar um tempo para compartilhar.: +1:)

@kzu Como @ Mike-EEE disse, não acredito que alguém esteja dizendo que queremos que o MSBuild ofereça suporte a JSON. O que meio que evoluiu de algumas das discussões é que a definição do projeto provavelmente deve ser baseada em JSON, e que a definição do processo de construção deve ser baseada em qualquer linguagem que a "grande" ferramenta de construção use (ou seja, XML para MSBuild).

Mas muitos builds não _necessitam_ de uma grande ferramenta de build, seu build é apenas para construir a definição do projeto, sem qualquer complexidade. Em caso afirmativo, por que o MSBuild seria necessário nesse caso?

Sem discutir que não deveria estar _disponível_, todos nós ocasionalmente precisamos de um sistema de construção poderoso. Mas não acredito que deva ser o padrão para todos os tipos de projeto.

Especialmente considerando que esta construção leve existe e está funcionando. São apenas as tentativas de transformá-lo em um análogo do MSBuild que causam o problema. Não deveria ser isso.

Não acredito que alguém esteja dizendo que queremos que o MSBuild ofereça suporte a JSON.

Bemlllll ... tecnicamente eu sou. : smile: (E Yaml, e Toml, e Xaml e ...)

Mas este problema (para gentilmente lembrar é para um Format Agnostic MSBuild, bem como um modelo / representação aprimorado via POCO) é um pedido / objetivo "eventual" ou futuro, não deve ser considerado no atual debate violento. Mas se puder influenciá-lo, tanto melhor. : +1:

Bemllllll, o MSBuild já tem uma representação POCO na memória dos arquivos, portanto, não deve ser muito difícil para alguém escrever outra serialização disso. Está tudo em Microsoft.Build.Construction ;)

E a partir desse modelo, você pode ver que os conceitos subjacentes não são complicados, IMO

Exatamente o que pretendemos aqui, @kzu!

Mas, para ser justo, acho que você quis dizer o namespace Construction . :sorriso:

O objetivo é que qualquer desenvolvedor possa "trazer seu próprio serializador" e o MSBuild "simplesmente funcione" bem com ele.

Atualmente, se você olhar os arquivos ( amostra ), verá que todos eles estão totalmente arraigados com modelagem / entidades centradas em XML, o que é o principal desafio no momento.

Também parece que eles não têm construtores públicos sem parâmetros, que não funcionarão imediatamente com a maioria dos serializadores.

Isso é verdade. Talvez seja "apenas" uma questão de POCO-izar um pouco mais esse conjunto
das aulas?

Na segunda-feira, 16 de maio de 2016 às 14h10 Mike-EEE [emailprotected] escreveu:

Atualmente, se você olhar nos arquivos (amostra
https://github.com/Microsoft/msbuild/blob/master/src/XMakeBuildEngine/Construction/ProjectItemElement.cs)
você pode ver que todos eles estão totalmente arraigados com XML-centric
modelagem / entidades, que é o principal desafio no momento.

Também parece que eles não têm construtores públicos sem parâmetros,
que não funcionará imediatamente com a maioria dos serializadores.

-
Você está recebendo isso porque foi mencionado.
Responda a este e-mail diretamente ou visualize-o no GitHub
https://github.com/Microsoft/msbuild/issues/613#issuecomment -219483928

Talvez seja "apenas" uma questão de POCO-izing um pouco mais esse conjunto de classes?

Bem e sabiamente dito. É uma ladeira escorregadia (ou desafiadora?). Se POCO-ize-los, então a lógica que está atualmente dentro dos objetos provavelmente se moverá para outras classes / serviços.

E também ... enquanto estamos lá ... estamos agora definindo "elementos" ou "objetos"? :) ProjectItemElement descreve ou alude à nomenclatura de documentos xml, enquanto ProjectItem parece muito mais com um POCO. Bem, para mim, pelo menos. :oculos escuros:

Não é uma tarefa pequena, mas é exatamente neste caminho que estou pensando.

@ Mike-EEE Não tenho certeza do que "msbuild agnóstico de formato" resolverá. Você ainda precisaria entender o conceito de propriedades, itens, tarefas, metas, ordem de avaliação, dependências etc. E como isso deveria funcionar? Todos escrevem em qualquer formato que quiserem e o msbuild pode ler / escrever todos eles - com base em extensões de arquivo ou algum cabeçalho nos arquivos?

Não tornará mais difícil para usuários "casuais" que procuram uma solução em stackoverflow etc, agora eles precisam mapeá-lo para qualquer formato que o projeto em que estão trabalhando esteja usando? Seria mais complicado ajudar as pessoas e ler + depurar arquivos de destino (alternância de contexto entre formatos diferentes, garantindo que o escape fosse feito corretamente nos arquivos).

Qual é o problema real que você está tentando resolver aqui?

Como @kzu disse, mover os padrões para arquivos props deve principalmente reduzir o arquivo csproj aos bits mais relevantes - lista de arquivos, referências etc, o que deve tornar mais fácil entender e editar.

Além disso, acho que seria bastante simples criar uma tarefa msbuild e os destinos que a acompanham que transformam um arquivo arbitrário em um arquivo MSBuild que pode ser importado. Com entradas / saídas adequadas, você nem perceberia;)

Para que isso funcione perfeitamente, precisamos permitir a importação dentro de um destino (aquele depois de gerarmos o MSBuild do YAML / JSON / Whatever) ....;)

Mas muitos builds não precisarão de uma grande ferramenta de build, seu build é apenas para construir a definição do projeto, sem nenhuma complexidade. Em caso afirmativo, por que o MSBuild seria necessário nesse caso?

Mesmo projetos C # regulares dependem da lógica nos arquivos Microsoft.*targets que fazem muitas coisas como - descobrir as referências de assembly, construir recursos, assemblies de satélite, fazer tudo isso para referências de projeto, certificando-se de que eles estão disponíveis para o compilador para usar, contabilidade para limpezas futuras, compilações incrementais, limpezas incrementais, enquanto fornece ganchos para permitir ao usuário ajustar o processo de compilação o mínimo ou o quanto for necessário. Muitas coisas acontecem "nos bastidores" nos arquivos e tarefas de destino do msbuild.

E se você estiver usando produtos como Xamarin.Android/iOS, que têm requisitos mais personalizados para trabalhar com outras ferramentas para construir, empacotar, implantar, ter estruturas de destino não-.net etc, então toda essa lógica vai para os destinos e tarefas do msbuild arquivos. O usuário ainda vê o csproj de aparência normal com os arquivos de origem / conteúdo, referências, etc. Toda a complexidade ainda está oculta nos arquivos de destino / tarefas.

E como isso deve funcionar? Todos escrevem em qualquer formato que quiserem e o msbuild pode ler / escrever todos eles - com base em extensões de arquivo ou algum cabeçalho nos arquivos?

Correto, pode ser uma combinação de soluções, e eu dei minha opinião no OP. Totalmente aberto à discussão / consideração! Isso é apenas para fazer a bola rolar. E parece que neste ponto está subindo uma colina muito, muito íngreme. :sorriso:

Não tornará mais difícil para usuários "casuais" que procuram uma solução em stackoverflow etc, agora eles precisam mapeá-lo para qualquer formato que o projeto em que estão trabalhando esteja usando?

O mesmo poderia ser dito com C # vs. VB.NET. : smile: Tenho certeza que você viu as diferenças dos projetos em diferentes formatos . Contanto que o modelo seja o mesmo, o formato não apresentará variação em como o modelo se comporta depois de desserializado, correto?

Qual é o problema real que você está tentando resolver aqui?

Existem três (que posso pensar no momento):

1. Um deles, como eu (tentei: sorrir:) afirmei no OP é que os desenvolvedores / organizações realmente amam seus formatos, especialmente após o movimento project.json (
2. O segundo é o das ferramentas. Aqui, eu trago o Xaml novamente porque acho que ele tem as ferramentas mais maduras construídas em torno dele. Aqui está um artigo que escrevi que meio que resume por que eu prefiro isso ao definir entidades de aplicativos . Se formos livres para usar qualquer formato que quisermos, podemos tirar proveito de qualquer ferramenta que já tenha sido criada em torno desse formato para trabalhar da forma mais produtiva possível.
3. Consistência. Não sei sobre você, mas prefiro trabalhar em C # para meu código. Se eu puder evitar, quero trabalhar no Xaml para todos os meus dados. Ter um formato consistente nas soluções reduz a complexidade, a troca de contexto e a confusão / aborrecimento geral. Desenvolvedores / organizações têm seus próprios formatos recomendados por causa disso.

Espero que isso ajude a esclarecer minha perspectiva. Com base no feedback até agora, estou / tenho feito um péssimo trabalho! : stick_out_tongue:

Para que isso funcione perfeitamente, precisamos permitir a importação dentro de um destino (aquele depois de gerarmos o MSBuild do YAML / JSON / Whatever) ....;)

Apreciando as ideias aqui, @kzu. Obrigado por fazer um brainstorming e fornecer ideias construtivas e feedback. : +1:

Só para ter certeza aqui, sou um velho skool aqui e tenho mais de uma década (intermitente!) De experiência passando por "scripts" do MSBuild. Estou "ok" com a experiência XML, mas definitivamente gostaria de vê-la melhorada, se puder ser ajudado. Meu objetivo / intenção aqui é também considerar / integrar o campo JSON e ajudar a melhorar a percepção / adoção do MSBuild e sua experiência de produto percebida (pobre).

@ Mike-EEE ajuda a melhorar a percepção / adoção do MSBuild e sua experiência de produto percebida (ruim).

Para mim, essa é uma solução simples: pare de torná-la o núcleo de todas as experiências de build .NET. O MSBuild é um sistema muito poderoso, mas é um exagero completo para 90% dos casos de uso.

Então aqui está uma pergunta simples. Eu entendo porque

msbuild project.xproj

Usaria o MSBuild. Eu entendo, estou feliz com isso.

Por que

dotnet build project.json

Usar o MSBuild exatamente? Quero dizer, você tem msbuild certo? O que dotnet build adiciona? Nada além de confusão. Se você vai descontinuar dotnet build com msbuild tenha a honestidade de realmente puxar o gatilho.

O negócio é o seguinte: se você não é um engenheiro de compilação / lançamento ou de outra forma intimamente familiarizado com o msbuild, é uma experiência péssima.

Sem entrar em formatos de arquivo específicos (não quero debater XML vs JSON vs YAML vs XAML) tudo que eu quero (e suspeito que muitos outros também fazem) é a capacidade de criar rapidamente um novo tipo de projeto padrão (montagem, aplicativo de console ) que pode construir e empacotar imediatamente em _qualquer_ plataforma .Net suportada que tenha _qualquer_ conjunto de ferramentas .Net instalado. ou seja, se eu tiver uma edição de luxo completa do Visual Studio instalada no Windows, o Core SDK no OS X ou o Core SDK instalado no meu servidor de compilação do Windows, posso apenas fazer:

1. git clone {qualquer}
2. {comando de construção específico da instalação}, por exemplo dotnet build ou Build - Build Solution

Não há "se você estiver usando o SDK, você precisa copiar esses destinos de uma máquina que tenha o Visual Studio instalado" e não preciso me preocupar com csharp.targets mágicos ou qualquer uma dessas bobagens.

É a diferença entre dizer:

1. aqui está uma lista de ingredientes para um bolo, vá fazer um bolo para mim

e

1. vá até a garagem e encontre esta lista de peças
2. pegue essas peças e monte-as em um carro
3. dirigir até a loja, seguindo esta rota
4. para cada ingrediente, encontre-o em
5. siga o seguinte caminho para casa
6. na seguinte ordem, façacom cada ingrediente
7. ...

Isso é muito bom se você está tentando fazer algo estranho, mas quando é algo simples como construir um assembly e empacotá-lo no pacote NuGet ou criar um programa simples de um assembly, o msbuild é um exagero. Não preciso nem quero toda essa cerimônia.

O erro foi tentar fazer com que o project.json fizesse tudo em vez de reconhecer que era realmente bom em um conjunto de tarefas, o msbuild é realmente bom em outro (muito maior) conjunto de tarefas e descobrir como fazê-los trabalhar juntos. É como um aprimoramento progressivo. Você pode começar com uma descrição de projeto declarativa simples e, quando precisar de todo o poder do msbuild, poderá adicioná-lo.

Algumas ferramentas para auxiliar no gerenciamento de arquivos de compilação seriam boas também ...

@ Mike-EEE Sim. Não pretendo dizer a @aolszowka para parar de discutir sua posição, no tópico. Mas seu argumento técnico sobre o IntelliSense está errado, não apenas na teoria, mas também na prática. Quando metade desta discussão é ocupada com as idas e vindas entre vocês dois naquele ponto específico, estamos todos perdendo tempo aqui.

Se os arquivos MSBuild adquirissem o mesmo suporte a IntelliSense que outros tipos de arquivo têm, mesmo que isso fosse feito por meio da geração de arquivos XSD (desde que essa geração fosse livre de atrito), outro ponto problemático do MSBuild seria eliminado da lista. Há muitos deles para marcar, no entanto. Alguns mais importantes do que outros (embora eu não me importe com XML neste contexto, não estou convencido de que qualquer outro formato seja uma "vitória" grande o suficiente para importar, por exemplo). A melhor ideia que já ouvi foi separar a definição do build da definição do projeto, por exemplo. Faça isso e torna-se a escolha do projeto usar MSBuild, Make, PSake ou qualquer outra solução que desejar. Na verdade, eu gosto principalmente do MSBuild, para ser honesto, embora comentários sobre "posers" (nunca construtivos) e "build mestres" indiquem que a ferramenta é muito complexa pelo menos para as tarefas simples, se não em geral. Uma boa ferramenta torna mais fácil realizar as tarefas simples e possível realizar as complexas. Não estou convencido de que o MSBuild, hoje, faça isso.

@wekempf
Não tenho nenhum problema em ser questionado sobre qualquer coisa que eu disse aqui; mas, por favor, reserve um tempo para testar e provar a si mesmo antes de me chamar.

Você poderia facilmente ter provado isso a si mesmo; como poderia ter qualquer pessoa neste tópico que não estivesse familiarizada com isso; mas, em vez disso, farei isso por você e por outras pessoas, na esperança de levar essa conversa adiante.

Se você abrir um novo arquivo MSBuild no Visual Studio e começar com a tag de projeto padrão, notará que não há Intellisense sendo fornecido a você (veja a captura de tela):

Agora, se adicionarmos os xmlns (basicamente importando o schema / xsd), você começará imediatamente a obter o Intellisense:

A especificação diz que os editores devem ser livres para fazer o download do local especificado; mas no caso do Visual Studio (e estou especulando neste ponto), parece que eles tomaram a decisão de armazenar em cache o XSD localmente para evitar a chamada da web. Você pode encontrar o XSD para Visual Studio 2012 localizado em C:\Program Files (x86)\Microsoft Visual Studio 12.0\Xml\Schemas\1033\MSBuild

O padrão XSD permite comentários; se você olhar para aquele arquivo, verá que já existem vários comentários disponíveis; para que eu pudesse mostrar isso rapidamente, simplesmente editei a documentação fornecida para ToolVersion

Espero que isso resolva suas preocupações e as de @Mike-EEE de que o Editor do Visual Studio realmente usa XSD para fornecer o Intellisense, conforme documentado pela Microsoft em vários lugares, já que o arquivo MSBuild nada mais é do que um documento XML.

@ colin-young

Isso é muito bom se você está tentando fazer algo estranho, mas quando é algo simples como construir um assembly e empacotá-lo no pacote NuGet ou criar um programa simples de um assembly, o msbuild é um exagero. Não preciso nem quero toda essa cerimônia.

Eu entendo e concordo com o sentimento aqui. Mas, "se tudo o que você está fazendo é criar um blog simples, usar C # é um exagero" também pode ser dito. O poder do MSBuild não é realmente o problema. A complexidade certamente é, mas pode haver algumas coisas que podem ser feitas para reduzir essa complexidade, pelo menos nos casos "simples". Talvez não. Mas descartar a discussão sobre isso é semelhante à alegação de que a Microsoft está descartando a discussão de tirar o MSBuild do ônibus.

Não quero debater XML vs JSON vs YAML vs XAML

embora eu não me importe com XML neste contexto, não estou convencido de que qualquer outro formato seja uma "vitória" grande o suficiente para importar, por exemplo

Eu gostaria de lembrar a todos que o propósito deste tópico é remover completamente a dependência do formato, para que não haja mais um debate / batalha :) Se alguém puder escolher o formato que deseja trazer para a mesa ( ou " Traga seu próprio serializador ", como vi em outra edição), então eles não apenas terão a liberdade de trabalhar com o MSBuild da maneira que melhor lhes convier, mas evitarão ter que discutir sobre o formato ideal (como acharem adequado) para usar em primeiro lugar.

A melhor ideia que já ouvi foi separar a definição do build da definição do projeto, por exemplo.

Este é provavelmente o maior / benéfico rendimento de todos os @shederman 's ranting a raving: smile

@aolszowka Você está simplesmente errado. Eu vou provar para você. Crie um projeto C #, adicione uma classe e veja você obter o IntelliSense.

Veja, você está argumentando a partir de um ponto de vista muito estreito. Você está 100% correto sobre como o editor XML fornece IntelliSense. Você também está 100% errado sobre como o Visual Studio fornece IntelliSense.

@wekempf Não estou tentando descartar nada da discussão aqui. Eu estava apenas tentando apontar que:

• provavelmente haverá muitas entradas de pessoas no campo "Eu nunca quero tocar no msbuild" se realmente acabarmos com o msbuild como o formato de projeto padrão, e eles terão motivações e requisitos muito diferentes do que o msbuild típico especialista / usuário avançado
• poderíamos realmente usar algumas ferramentas melhores para editar arquivos msbuild (não estou tocando na discussão XML / XAML / Intellisense, pois não tenho nenhum cão nessa caçada)
• talvez estejamos (estou?) tentando atacar 2 problemas diferentes ao mesmo tempo
  
  
  
  • uma descrição declarativa da finalidade e resultados de um projeto
  
  
  • instruções sobre como conseguir isso
  
  

Qualquer discussão sobre maneiras de melhorar o msbuild são importantes, IMHO.

@kzu é um pouco difícil comentar sem saber como ficarão os formatos do arquivo final. Na verdade, eu só queria expressar minha experiência com o que gosto em project.json e como ele eliminou uma classe de problemas que historicamente encontrei ao tentar construir coisas em servidores de construção sem periféricos. Continuarei acompanhando as mudanças mais recentes no ecossistema .Net e continuarei a expressar minha opinião quando sentir que alguns de meus recursos favoritos podem estar sob ameaça.

Acho que o problema é que agora um arquivo MSBuild (.csproj, .vbproj, etc) é tratado apenas como um arquivo XML. Isso significa que ele obtém apenas o provedor de intellisense XML, que é inteiramente baseado no XSD fornecido, como @aolszowka apontou repetidamente.

Em vez de sugerir que o MSBuild consuma tipos de arquivos arbitrários (json, yaml, XAML, etc), o que eu acho uma ideia irreal (e também uma ideia ruim), acho que faria sentido sugerir que haja um padrão Provedor de intellisense para arquivos MSBuild. Por exemplo, quando eu digito "$ (", o provedor intellisense pode ser inteligente o suficiente para fornecer uma lista completa de todas as propriedades que estão atualmente no escopo. O mesmo para "@ (" e itens. A navegação F12 para itens e propriedades seria também tornam os arquivos MSBuild muito mais fáceis de criar. Acho que isso é o que as pessoas estão realmente pedindo, elas querem que seja mais fácil de criar. XAML é mais fácil de criar porque tem um suporte Intellisense muito bom. Esse intellisense vem do objeto rico modelo que direciona o XAML. Há muitos "metadados reflexivos" que podem ser disponibilizados para um arquivo MSBuild sem recriar completamente sua natureza fundamental (XML).

Por que acho que formatos arbitrários são uma má ideia? Estou feliz que você perguntou. Porque significa que quando eu entrar em um novo projeto, provavelmente terei algum novo tipo de arquivo de compilação para aprender. Não concordo com a opinião de que json é de alguma forma magicamente mais fácil de mesclar do que XML. Ambos podem ser fáceis de mesclar ou um desastre, dependendo da formatação e da estrutura. XAML é apenas XML, portanto, claramente não pode ser mais fácil (ou mais difícil) de mesclar.

Acho que muito pode ser feito para simplificar os modelos de projeto padrão e torná-los mais fáceis de manter, mas essa é uma discussão completamente diferente (que está acontecendo atualmente em outros repositórios do github).

Esse intellisense vem do modelo de objeto rico que impulsiona o XAML

Para ter certeza, esse modelo de objeto rico é na verdade a (s) definição (ões) de classe do (s) .NET POCO (s) com os quais você trabalha, que é o que pretendemos aqui. É poderoso (e dinâmico) porque se você alterar uma propriedade para seu POCO, você alterará automaticamente o esquema para o documento no qual está criando. Esta é uma dinâmica chave que ainda não encontrei em nenhuma tecnologia de serialização e é (uma das muitas razões) por que prefiro o Xaml.

Um dos problemas (latentes) que estamos encontrando é que "$ (" e "@ (" não são realmente baseados em POCO's ou qualquer coisa .NET, mas são em última instância strings mágicas (por falta de uma palavra melhor) que são nativo para DSL do MSBuild (XML), e não necessariamente qualquer coisa em .NET. Se não estiver vinculado a um modelo .NET (POCO), então há uma grande quantidade de trabalho (desnecessário) necessário para construir o modelo para torná-lo amigável à ferramenta (XSD vindo à mente aqui) e, como resultado, deve ser uma abordagem de design que seja evitada de maneira ideal.

Porque significa que quando eu entrar em um novo projeto, provavelmente terei algum novo tipo de arquivo de compilação para aprender.

Agora você sabe como a equipe JSON está se sentindo atualmente. : smile: Esperançosamente, se você entrar em uma equipe (funcional), uma das discussões que eles (deveriam) ter na frente são coisas como formatos preferidos e regras de formatação / estilo de código. O que significa que você deve ter uma opinião (voto) sobre o tipo de formato que prefere. Ter opções permite que mais vozes sejam ouvidas e, com sorte, contribui para uma melhor experiência de equipe.

@MarkPflug Sim, isso é principalmente o que @Mike-EEE estava defendendo. Você precisa ir um pouco mais fundo, porque o MSBuild é um sistema "extensível" e, atualmente, a única maneira de o IntelliSense saber como trabalhar com essas extensões é por meio de XSD. Ou esse XSD precisa ser gerado a partir da fonte (por exemplo, o código C # que implementa uma nova tarefa) automaticamente ou, melhor ainda, eliminamos a necessidade de XSD totalmente, como o editor XAML fez. Não há mais rabiscos para coisas como SccAuxPath. IntelliSense para referências $ (). IntelliSense para argumentos arbitrários para novos elementos de tarefa sem a necessidade de gerar manualmente um XSD.

Outras coisas que ajudariam:

1. Suporte total para NuGet. Em vez de presumir que os arquivos .target estão em algum lugar no sistema de arquivos, especifique as referências do NuGet para eles, resolvendo o problema de "inicialização" no processo. Além disso, adicionar uma referência NuGet não deve exigir que o arquivo de projeto e o arquivo packages.config sejam modificados. Com muita frequência, um é modificado corretamente e o outro não, deixando você com uma bagunça para limpar.
2. Suporte "adequado" para curingas (sim, isso é principalmente um problema do Visual Studio, não um problema do MSBuild).
3. Não requer descarregar / editar / recarregar. Sim, isso é inteiramente um problema do Visual Studio, mas este é o único lugar razoável para trazer essa discussão.
4. Algumas considerações sobre como reduzir conflitos de mesclagem. (2) pode percorrer um longo caminho nesse sentido. Não reclamamos tanto sobre conflitos de mesclagem em arquivos XAML, provavelmente porque eles são editados com menos frequência e editados de uma forma que geralmente mantém a estrutura, enquanto simplesmente adicionar um arquivo de classe hoje pode resultar em vários conflitos.

Esses são os grandes, mas há muitos outros pontos fracos com o MSBuild. Como eu disse, a necessidade de ter um "mestre de construção" é reveladora aqui.

@wekempf

1. Portanto, o MSBuild depende do NuGet. Agora preciso inicializar o NuGet. Estou trocando um problema de bootstrap por outro. Precisa haver "algo" na máquina para permitir a construção. Agora é o MSBuild e um conjunto bem conhecido de arquivos de destino.
2. Isso NÃO é um problema do MSBuild. É inteiramente um problema do sistema de projeto do Visual Studio. Há discussões em andamento no repositório AspNet / Home em torno desse problema agora, eu acredito.
3. Novamente, um problema do VS, não um problema do MSBuild. Se você usa o VSCode, esse problema não existe.
4. Eu concordo aqui até certo ponto. A dificuldade em mesclar o tipo .csproj atual é devido à maneira como o VS o atualiza. Se fosse mais rigoroso quanto à ordem dos arquivos (alfa), ou se usasse globbing includes (que eu acho que é a proposta atual) **/*.cs , isso também aliviaria esse problema.

Liste os "outros pontos fracos" do MSBuild para que tenhamos algo com que trabalhar. Este argumento de que precisamos de um especialista para usar o MSBuild é verdadeiro, da mesma forma que você precisa de um "especialista" em C # para escrever código C # ou de um especialista em Node para escrever coisas de node.js. Sim, coisas complexas requerem perícia para serem dominadas, isso é um fato.

@wekempf @ Mike-EEE
Portanto, para reformular sua pergunta de outra maneira: Você gostaria de uma Interface do Editor centrada no MSBuild para o Visual Studio? (Semelhante às superfícies do designer para outros tipos de arquivo, como Arquivos de recursos, XSD Explorer e o Editor Xaml).

Essa é uma pergunta muito diferente na minha opinião do que o que estava sendo postado aqui.

Embora seja algo que eu acho que seria útil; se eu fosse solicitado a comparar isso com outras necessidades do ecossistema do Visual Studio, eu pessoalmente colocaria isso no mínimo. No entanto, eu ainda votaria.

Por que vale a pena, o depurador não documentado entendeu o suficiente sobre a sintaxe $() e @() para fornecer uma visão um tanto utilizável dessas propriedades e grupos de itens; isso poderia ser aproveitado?

Você gostaria de uma Interface do Editor centrada no MSBuild para o Visual Studio?

Bem, feche. Você mencionou o editor Xaml, então vou usá-lo porque esse é precisamente o paradigma que estou buscando aqui. No entanto, por que criar um editor / interface totalmente novo quando o editor Xaml que você mencionou e que está no VS funciona perfeitamente bem para definir / descrever _qualquer_ POCO que você possa imaginar?

Hoje. Sem instalações, modificações ou mágica do tipo.

Conseqüentemente, o que está sendo solicitado aqui é um modelo baseado em POCO para descrever documentos MSBuild. Feito isso, ele pode aproveitar as vantagens das _ferramentas que já existem no Visual Studio_ para descrever / definir esses documentos. Além disso, abrir o formato para qualquer formato / serializador disponível abre ainda mais as opções (para outros IDEs / ferramentas diferentes do VS, ou mesmo editores dentro do VS).

Então eu acho que devo dizer que ... o conjunto de ferramentas / editor / interface já está disponível no Visual Studio, é apenas que o MSBuild precisa evoluir / atualizar-se para que possa ser compatível com ele e tirar proveito dele, se isso torna senso.

@ Mike-EEE Estou tentando imaginar como seria uma solução de compilação baseada em XAML.

Imagine que eu queira personalizar meu processo de construção. O que está envolvido? Eu preciso definir um POCO? Ok, escrevo um novo arquivo C #. Presumivelmente, gostaríamos de oferecer suporte a qualquer linguagem .NET, VB, F #? Uma vez que eu tenho meu tipo de tarefa definido, isso fica em um novo projeto em algum lugar, certo? Eu preciso construí-lo em uma montagem? Bem, temos um problema de compilação recursiva em que pensar agora, mas certamente podemos resolvê-lo. Esse assembly precisa ser referenciado no XAML. Agora, eu tenho o intelliense em meu arquivo XAML, então posso ter mais facilidade para escrever meu script de compilação original.

Na verdade, isso não parece estar tornando a experiência "geral" mais fácil para mim. Isso está facilitando uma pequena parte do processo de autoria do build.

Se estou interpretando mal sua sugestão, por favor, esclareça.

@ Mike-EEE Eu entendo que você ama o XAML. Mas, honestamente, o XAML não fará nada para atrair desenvolvedores não MS para o ecossistema. Obviamente, o MSBuild não será reescrito para oferecer suporte APENAS a XAML. Acho que podemos concordar que isso nunca vai acontecer. Então, você está pedindo suporte para XAML além do formato XML existente que temos hoje? Por que você quer XAML? Meu entendimento é que você deseja o provedor XAML intellisense ao editar seus arquivos de construção. O provedor XAML intellisense não vai dar a mesma experiência que project.json forneceu de qualquer maneira. O preenchimento automático em pacotes nuget requer a consulta dos repositórios nuget, que não é algo que o XAML irá fornecer magicamente.

As pessoas adotaram a simplicidade de project.json, mas acho que só é verdade quando comparado à complexidade atual do formato de arquivo .csproj padrão. Não há razão para que o modelo padrão precise conter tudo o que faz hoje. Se você tiver uma construção simples, seu arquivo .csproj poderia ser tão simples quanto importar o "Microsoft.CSharpDefaults.targets" (isso não existe hoje, estou imaginando como as coisas poderiam ser). Além disso, o arquivo .csproj pode ser dividido em partes separadas. Talvez todas as suas dependências do NuGet residam em um arquivo msbuild separado (semelhante a packages.config) que é incluído para você, e esse arquivo em particular receberia suporte intellisense (e UI) do VS; também não exigiria descarregar / recarregar.

Na verdade, gosto muito de XAML também. É uma ótima ferramenta para o que foi projetado. Só acho que você realmente precisa considerar o que, e mais importante por quê, é o que você está pedindo.

@wekempf isso pode ser feito _hoje_. Aqui está um arquivo em lote trivial que baixa nuget.exe, restaura pacotes de script de compilação de um packages.config (que pode incluir MSBuild ou a versão do MS uma vez que é enviado, mais os compiladores MS , mais as Tarefas e destinos NuGet - alguém precisa empacotar esses como outro nuget;)).

Meu ponto é que estamos muito mais próximos com as ferramentas _existentes_ de alcançar essa experiência perfeita do que muitos pensam. @MarkPflug bootstrapping MSBuild, NuGet e os compiladores .NET está ficando mais fácil a cada dia agora.

Na verdade, isso não parece estar tornando a experiência "geral" mais fácil para mim. Isso está facilitando uma pequena parte do processo de autoria do build.

Com certeza. Se você sabe alguma coisa sobre o processo de compilação do TFS, sabe que isso foi / é um pesadelo. Fazer com que todas as montagens sejam resolvidas corretamente e, em seguida, configurar o ambiente. Aborrecimento total e uma experiência terrível / (e eu diria o nome) para Xaml.

Então, depois de se gabar de que não há nenhuma instalação ou mágica (naturalmente: sorria :), o ponto que você fez é bastante saliente, pois atualmente o designer Xaml funciona perfeitamente no esquema csproj atual. Suas referências / montagens / projetos são resolvidos a partir de tal. É claro que isso teria que mudar com o novo formato. O arquivo csproj (lembre-se de que é um POCO serializado) obteria todas as suas referências / dados ... de si mesmo? Outro arquivo? Esta é uma consideração / preocupação com ferramentas que certamente precisa ser resolvida.

Mas, honestamente, o XAML não fará nada para atrair desenvolvedores não MS para o ecossistema

Entãããão isso é um "sim" ao suporte de outros formatos, então? :sorriso:

Por que você quer XAML? Meu entendimento é que você deseja o provedor XAML intellisense ao editar seus arquivos de construção.

Bem, isso é parte disso. É a experiência geral com ferramentas e também design. Eu explico aqui porque o Xaml é melhor do que o modelo app / web.config e project.json, e também explico aqui porque ele oferece uma experiência IDE melhor. A chave com o último é que ele se presta muito bem para design visual em potencial. O que é ótimo para complementar a abordagem de design de texto.

O preenchimento automático em pacotes nuget, exigindo a consulta aos repositórios nuget, não é algo que o XAML irá fornecer magicamente.

Isso é verdade, mas na minha opinião não deveríamos usar um editor de texto para definir essas coisas. :) Em vez disso, devemos usar a maravilhosa IU que foi construída em torno do NuGet Package Manager e ter uma melhor integração com os arquivos com os quais eles interagem e / ou criam (IMO, é claro - tenho certeza de que há pelo menos _um_ pessoa que discorda de mim: wink :). O que leva ao seu próximo ponto:

(isso não existe hoje, estou imaginando como as coisas poderiam ser). Além disso, o arquivo .csproj pode ser dividido em partes separadas.

Isso é ótimo! Não, não tenho todas as respostas e estou apenas começando a conversa. E eu concordo com os arquivos separados. Isso é algo de que o sistema TFS Build poderia ter se beneficiado _tremendously_. Definitivamente sou pró-Xaml, mas não estou preso por ser o único formato, mas acho que deve ser _um_ dos formatos suportados.

Basicamente, no meu mundo, "todos os caminhos levam ao MSBuild". Se essa estrada é construída em XML, JSON, XAML, YAML, TOML, depende do aventureiro que faz a jornada. Como é isso para algum potencial de marketing cafona? Ha ha. :sorriso:

Basicamente, no meu mundo, "todos os caminhos levam ao MSBuild".

Só para ser muito, muito claro: para muitas pessoas essa afirmação não é válida. Certamente não vejo razão para que o MSBuild deva ser executado por dotnet build menos que eu diga algo explicitamente (em project.json, ou pela presença de um arquivo xproj ou qualquer outro) para usar msbuild.

Se você escolher digitar msbuild , vejo todos os motivos pelos quais _que_ deve executar o MSBuild 😉

A discussão dos formatos de arquivo deve ser adequada ao propósito. XML tem um lugar para sistemas de construção complexos e poderosos com grande capacidade de personalização. O mesmo acontece com o XAML. Eu concordo que em tal sistema JSON pode não ser ideal, embora minha preferência seja pelas definições de compilação fornecidas por Roslyn ala sbt ou gulp , mas esse é um argumento diferente.

XML, no entanto, é um exagero para uma _definição de projeto_ com um esquema estático, nunca mudando. É desnecessariamente detalhado e adiciona um nível de autodocumentação que é apenas 100% desnecessário para um esquema estático.

Então, por que meu build simples que apenas constrói a definição do projeto requer MSBuild?

Não ouvi nenhuma razão válida para isso. Basta entregar o lixo ondulado de pessoas pró-MSBuild falando sobre como ele é poderoso. Sim, é, mas é uma faca que corta as duas direções.

Eu entendo por que Build Masters como @aolszowka têm interesse em empresas como a minha que usam Build Masters para compilações pequenas e simples; mas é apenas uma perda de tempo e dinheiro, e não faz nenhum sentido econômico para mim.

O .NET Core é um programa de trabalhos para MSBuild Build Masters? Ou é um _framework_ para o desenvolvimento de software eficaz?

A discussão dos formatos de arquivo deve ser adequada ao propósito.

Ah, mas novamente no meu mundo não há discussão sobre formatos. Você escolhe o formato que prefere e gosta mais, com as melhores ferramentas para apoiá-lo. Veja como meu mundo é ideal, tão perfeito, tão puro, tão fantástico e maravilhoso ... tão completamente inexistente e desprovido de realidade. :rindo:

XML, no entanto, é um exagero para uma definição de projeto com um esquema estático, nunca mudando. É desnecessariamente detalhado e adiciona um nível de autodocumentação que é apenas 100% desnecessário para um esquema estático

Corrija, de acordo com _sua_ preferência e forma de abordar os problemas, que pode ser mais ideal, proficiente e eficiente. Mas pode não ser o caso para outros, onde essa verbosidade é _familiar_ e, como tal (ironicamente), os torna mais eficientes e proficientes. :) Por que queremos negar a eles sua preferência? Mais uma vez, volto ao espírito original do .NET: construa seu aplicativo na linguagem de sua preferência. Aqueles que preferem C # podem olhar para todas as qualidades negativas do VB.NET e dizer porque é uma linguagem inferior. E aqueles que (cada vez mais, devo acrescentar - estou me transformando em um deles!) Preferem F # olham para todas as qualidades negativas do C # (OO) e defendem por que é mais caro construir aplicativos usando seu conjunto de recursos.

Mesmo assim, ainda existem especialistas em C # que podem criar soluções mais baratas nessa linguagem do que em F #. Então, o que é "melhor?" Este argumento / discussão tolo é o mesmo que vejo sempre que vejo formatos de dados. O "problema" não é o formato, mas a tecnologia que dita / impõe um e apenas um. Isso é o que eu estava tentando fazer com a analogia da estrada (parece que essa, também não pegou, LOL!).

Portanto, para (espero) resumir: opções - como a ganância - são boas. :sorriso:

opções - como a ganância - são boas.
O "problema" não é o formato, mas a tecnologia que dita / impõe um e apenas um
construa seu aplicativo na linguagem de sua preferência

👍

Cara, contanto que eu não tenha que colocar minha definição de projeto em XML, e eu não tenha o MSBuild rodando quando eu dotnet build , eu realmente não me importo com quais outros formatos são suportados.

@shederman Isso é como dizer que, desde que sempre que você escrever C #, ele é compilado com compilador tal e tal e é AOT'ed em vez de JIT'ed e em tempo de execução dos usos GC que o algoritmo em vez de que outro e que-não, " você realmente não se importa ".

por que você se importaria com o que acontece nos bastidores, contanto que você escreva C # ou "não-XML" como neste caso?

Cara, contanto que eu não tenha que colocar minha definição de projeto em XML, e eu não tenha o MSBuild rodando quando eu construo dotnet, eu realmente não me importo com quais outros formatos são suportados.

Parece que ouvi um voto para o formato .INI !!! : smiling_imp:: smiling_imp:: smiling_imp:

@kzu Na verdade não é o que estou dizendo.

Mais como, estou escrevendo um aplicativo de console e está funcionando bem, e agora você está propondo colocar uma camada OWIN em aplicativos de console. Eu entendo que é poderoso e flexível. Eu entendo que funciona bem para casos de uso grandes e complexos.

Mas não entendo por que preciso disso em meu aplicativo de console.

@kzu Ah, e a propósito, eu _posso_ escolher entre JIT e nativo e _posso_ escolher o algo GC e _posso_ entrar em seções de baixa latência e _posso_ escolher entre C # e F #.

Mas eu _não_ posso escolher entre a construção simples e a complexa aparentemente.

ISSO é um passo longe demais. 😕

@kzu Jogar em um arquivo em lote é trapaça. Primeiro, você não é mais um build baseado em MSBuild. Você é um build baseado em arquivo batch que usa o MSBuild internamente: P.

No entanto, eu poderia fazer a mesma coisa usando outro arquivo MSBuild (na verdade, já fiz, muitas vezes). Ainda é trapaça. O IDE não sabe como usar esse conceito de amarração de inicialização. Clone o projeto e abra a solução no IDE e a primeira construção irá falhar. Este não deveria ser o caso.

@wekempf Que tal declarar a restauração como parte do destino BeforeBuild ? Ainda está contido no MSBuild.

Se o seu objetivo é fazer com que o Visual Studio inicialize conforme necessário, esse é o lugar para fazê-lo. O ideal é lançar a lógica em um include comum e, em seguida, fazer com que cada um dos projetos faça referência a esse destino. O MSBuild detectará automaticamente que o destino foi executado pelo menos uma vez, portanto, você não deve se preocupar em manter o controle se ele foi inicializado ou não.

@wekempf , desafio você a clonar esse repo e fazê-lo falhar na primeira compilação;).

Se estiver abrindo o código-fonte no IDE, você já tem o MSBuild. Todo o resto são pacotes nuget, que tanto o IDE quanto o arquivo em lote e o MSBuild sabem como lidar. Essa é a mágica do MSBuild (desta vez para minha "restauração de pacote nuget de plataforma cruzada definitiva"), mais uma vez.

@kzu Essa é a magia do MSBuild

E, no entanto, muitos desenvolvedores parecem não gostar, apesar dessa "mágica".

Não quero polarizar mais essa discussão, mas acho que o lado @shederman dessa discussão precisa de mais suporte. Estou no campo de não estar contente com o MSBuild em sua encarnação atual. Embora agregar uma melhor experiência de editor ajude, é apenas um remédio para um sintoma de um problema subjacente mais profundo.

Para mim, o problema com o MSBuild é que ele é muito complexo. Ele é construído de uma forma que torna qualquer serialização (XML, YAML, JSON, o nome dela) de seu modelo de objeto um pesadelo para trabalhar. Para garantir um formato bonito, a serialização precisa ser mais do que apenas um despejo textual de um modelo de objeto. Ele precisa ser feito sob medida para garantir que tenha uma aparência elegante e intuitiva para um desenvolvedor em qualquer editor de sua escolha.

A representação textual usada para conduzir o mecanismo de construção precisa ser uma abstração simplificada do modelo de objeto. Precisa ser fiel ao formato escolhido e deve ser percebido como elegante e fácil de escrever. Embora seja totalmente possível fazer em XML (acho que XSLT é uma linguagem bastante elegante baseada em XML, por exemplo), não é o caso com MSBuild.

Para se inspirar em como um sistema de compilação simples e elegante para .NET pode ser, verifique o Cake , que com pouco esforço pode ser tão extensível quanto o MSBuild, mas sem toda a complexidade de ter XML e MSIL pré-compilado (Cake é tudo apenas C # na forma textual; o Cake faz a compilação para você com Roslyn) e com um modelo de objeto muito, muito mais simples.

O bolo, junto com o que project.json fez, cobriria bem mais de 99% do que todos usam o MSBuild hoje. Só que a maioria das pessoas não odiaria, que é minha experiência como arquiteto de software e desenvolvedor líder para grandes equipes de desenvolvimento na plataforma .NET desde a primeira versão beta do .NET 1.0 enviada em 2000.

Agora, não estou defendendo a substituição do MSBuild pelo Cake (embora isso tenha meu apoio de aplausos, torcidas e água nos olhos), mas estou tentando envolver aqueles que acreditam que os problemas do MSBuild são possíveis corrigir com serialização diferente ou uma melhor experiência de editor entenda que eles estão errados, e talvez o Cake possa funcionar como um abridor de olhos.

Uma pequena pepita interessante por aí para ajudar a apoiar o caso de POCO. O poderoso Rick Strahl entende: https://weblog.west-wind.com/posts/2016/May/23/Strongly-Typed-Configuration-Settings-in-ASPNET-Core

É claro que isso está usando ASP.NET Core, portanto, está em JSON. Mas, novamente, uma vez que você está trabalhando diretamente com um modelo de objeto (e não um modelo de objeto de documento), você pode utilizar qualquer mecanismo de serialização que desejar (enquanto usa as ferramentas correspondentes junto com ele). Certamente é uma maneira diferente de pensar, mas espero que esse tipo de exemplo ajude a demonstrar o que buscamos aqui.

Dado que este problema provavelmente NUNCA vai acontecer, acredito que uma ferramenta sã que gere e produza arquivos XML msbuild É possível como um projeto comunitário. Para aqueles desenvolvedores que odeiam o MSBUILD e que dedicaram tempo e energia consideráveis ​​para entender a loucura que existe ali, ESPERAMOS que a Microsoft melhore a história, mas NÃO ACREDITAMOS.

Aqui estão as alternativas em que estou pensando:

1. BOLO. DSL baseado em AC # para sistemas de construção elegantes. Se a solução interna de MS não me ajudar, essa é a direção que estou seguindo. Estenda o bolo para gerar e invocar msbuild, e mover minha "orquestração" de construção para CAKE.
2. Um editor "msbuild on rails", eu acho, deve ser o que a própria Microsoft está fazendo, e estou pensando que é o que 90% dos desenvolvedores que estão loucos por deixar o Project JSON aceitarão.

Para aqueles desenvolvedores que odeiam o MSBUILD e que dedicaram tempo e energia consideráveis ​​para entender a loucura que está lá

Excelentemente disse @wpostma! <3

Acho que o que se perde em todas essas solicitações é que muitos de nós gastamos mais de uma década nessa API. Isso não é algo em que estamos saindo da rua e fazendo pedidos do nada. Somos usuários fiéis e antigos e queremos ver o MSBuild evoluir e melhorar para refletir as expectativas atuais do mercado. Pelo menos, é como me sinto. 😄

cake , bau , bounce , nake , psake , fake , fstoml , ...

Todas essas ferramentas de automação de compilação para .NET mostram que há muito espaço e desejo por alternativas ao msbuild clássico. Suponho que todos eles poderiam se beneficiar da abordagem POCO proposta nesta edição, de uma forma ou de outra.

Acho que outra coisa que está se perdendo aqui é a infeliz fusão do que considero o script de construção com a definição do projeto.

No MSBuild, minha definição de projeto é a mesma que minhas instruções de construção. Não há realmente outra linguagem em que eu possa pensar que seja esse o caso. O formato JSON é excepcional como definição de projeto, mas terrível como um conjunto de instruções de construção. Acho que as pessoas que têm mais problemas com o project.json estão chegando lá porque já construíram um conjunto robusto de instruções de construção no formato XML existente, enquanto as pessoas que realmente gostam de project.json estão usando mais ou menos padrões de construção.

Como alguém que lutou bastante com a estrutura XML horrivelmente mal documentada do MSBuild com seus montes de pegadinhas e esquema totalmente instável, eu honestamente gostaria de questionar a sanidade de qualquer um que sugere que é mais fácil lidar com ele do que criar scripts. No entanto, eu também entendo o ecossistema e o investimento que a criação manual de alguns csproj exige, então vou parar por aí.

Acho que o ideal está no meio: um arquivo de definição de projeto que seja facilmente editável à mão, sucinto e mesclado bem, separando a própria definição de construção para obter o máximo de flexibilidade. É por isso que eu realmente gostei do project.json, porque ele satisfazia o ângulo da simplicidade enquanto permitia escolher qualquer sistema de construção que você achasse mais conveniente. Agora, se apenas o VS permitisse que você conectasse seus próprios comandos de construção, o desemaranhamento estaria completo. Então você poderia usar cake, fake, psake, etc com o suporte VS "Build my solution", e aqueles que ainda gostariam de usar o MSBuild devido a problemas de legado, investimento de tempo ou simplesmente preferência poderiam fazer o mesmo.

Portanto, para reiterar o propósito deste problema: não é uma solicitação para suportar um formato específico (JSON / XML / etc) no sentido tradicional, mas para mover para _um modelo baseado em POCO_ que permitirá serializá-lo em _qualquer_ formato que você deseja (com XML e / ou JSON idealmente sendo suportado fora da caixa). Uma vez que ele seja capaz de ser serializado / desserializado em qualquer formato específico, você, como desenvolvedor / equipe, está livre para usar as ferramentas com as quais se sentir mais confortável para descrever seus arquivos de construção, assim (em teoria 😄) maximizando sua eficiência de desenvolvimento.

A ideia não é restringir a um formato particular (o que parece ter sido a estratégia perigosamente divisiva empregada até agora), mas permitir que os desenvolvedores e suas equipes _escolha_ para desenvolver seus arquivos de construção no formato em que eles sentem que são mais confortável e produtivo.

Resumindo, o suporte apenas para JSON ou apenas XML é tão ruim quanto criar uma solução em que suporte apenas C # ou apenas VB.NET. Mesma diferença. Obviamente, temos a capacidade de criar projetos .NET em qualquer linguagem .NET com suporte. No mesmo espírito, a pergunta análoga aqui é a capacidade de criar arquivos MSBuild em qualquer formato de dados compatível (já que todos seriam baseados no mesmo modelo POCO).

BTW / FWIW, estou muito feliz em ver os votos positivos para este item atualmente em 40, o que o torna de longe a questão mais votada neste repo a esse respeito:
https://github.com/Microsoft/msbuild/issues?q=is%3Aissue+is%3Aopen+sort%3Areactions-%2B1-desc

Obrigado a todos que apoiaram esta ideia!

E como projetar para projetar obras de referência neste mundo ideal? Como um script de construção arbitrário pode coordenar artefatos com suas referências de projeto que podem usar qualquer coisa?

Como a construção incremental funcionaria dentro do IDE? (FWIW, Cake tem _não_ suporte para compilações incrementais).

"Qualquer um" poderia escrever uma extensão de editor incrível para editar o MSBuild. Não há necessidade de extensões de produtos principais, ACHO

E como projetar para projetar obras de referência neste mundo ideal? Como um script de construção arbitrário pode coordenar artefatos com suas referências de projeto que podem usar qualquer coisa?

Receio que você terá que fornecer um pouco mais de contexto em torno deste. Se um arquivo de compilação tem alguns recursos que estão geralmente / genericamente disponíveis - como em um dicionário de recursos - e inclui outro arquivo de compilação de alguma forma (que pode ou não ter seu próprio dicionário de recursos), ambos devem ser capazes de acessar recursos uns dos outros de forma genérica. Isso pode e deve ser feito por meio do uso de chaves de string básicas e fortemente digitadas. O WPF usa um modelo parecido com este e tem sido muito bem-sucedido e popular.

Em qualquer caso, estes parecem problemas / questões muito rudimentares, nos quais outros muito mais difíceis foram respondidos pelos engenheiros talentosos por trás das paredes da MSFT. Mas, estou honrado que você me perguntou pensando que eu poderia ter uma resposta melhor. :)

Como a construção incremental funcionaria dentro do IDE? (FWIW, Cake não tem suporte para compilações incrementais).

Com compilações incrementais, você está se referindo a construir apenas os artefatos / código que mudou desde a última compilação? Nesse caso, posso estar um pouco perdido aqui, pois isso não tem muito a ver com este pedido / pergunta. Esta questão aqui está pedindo um modelo baseado em POCO para descrever as tarefas e itens que, por sua vez, forneceriam esses tipos de funcionalidade e recursos.

"Qualquer um" poderia escrever uma extensão de editor incrível para editar o MSBuild. Não há necessidade de extensões de produtos principais, ACHO

Não tenho certeza se você ainda está no mundo ideal aqui ou no mundo real aqui. Se for no mundo real, direi que é bastante revelador / interessante / pressentimento que ninguém tenha feito isso até agora. 🙁 Por favor, corrija-me se eu estiver errado. Ninguém parece ser um fã do DOM MSBuild atual e o que é pior é que parece que ninguém parece querer - ou _que quis_ - melhorar sua experiência por meio de ferramentas / extensões.

Independentemente do mundo real ou ideal, também não tenho certeza de como isso seria feito sem uma extensão. Todo editor que estende um formato que eu conheço ( exemplo 😄) está no mercado do Visual Studio como um download / instalação / extensão. A menos que haja alguma mágica que você conheça, uma extensão / instalação de algum tipo seria necessária.

Eu quis dizer que, assim como há uma miríade de provedores de intellisense para formatos / esquemas json (que levaram algum tempo para aparecer também, aliás, não é culpa do formato), sem exigir qualquer alteração no formato json ou modelo de dados, não há necessidade para tal mudança no núcleo do MSBuild a fim de fornecer uma melhor experiência de edição no topo.

Incluindo vê-lo como algo diferente dentro do VS, se você quiser. O fato de ninguém ter feito isso só mostra como há pouco esforço para isso. Assim como não houve necessidade de fornecer uma experiência de edição incrível para arquivos de configuração .net durante anos e anos.

Quer dizer, editar aquela coisa não é ciência de foguetes: p. Eu faço muito bem e adoro, mesmo que às vezes eu desejasse que houvesse algo um pouco mais integrado.

Incluindo vê-lo como algo diferente dentro do VS, se você quiser. O fato de ninguém ter feito isso só mostra como há pouco esforço para isso. Assim como não houve necessidade de fornecer uma experiência de edição incrível para arquivos de configuração .net durante anos e anos.

Gostaria de salientar que este era um sintoma do estado do Ecossistema .Net até recentemente. Era de se esperar que a única solução fosse a da Microsoft, e os pontos problemáticos foram resolvidos ou corrigidos a portas fechadas. Havia, e há, uma enorme massa de desenvolvedores de "matéria escura" que simplesmente pegavam tudo o que a Microsoft entregava e usavam (ou eram orientados a usar por executivos), estivessem ou não satisfeitos com isso. O fato de esse problema existir e ter estado tão ativo como é é uma prova disso.

Quer dizer, editar aquela coisa não é ciência de foguetes: p. Eu faço muito bem e adoro, mesmo que às vezes eu desejasse que houvesse algo um pouco mais integrado.

Não, mas está bem perto. Conheço uma grande quantidade de pessoas que ficaram completamente perplexas com os recursos do MSBuild, como envio em lote e transformações, e foram essas pessoas que tentaram. A maioria dos desenvolvedores que conheço nem sequer toca em .csproj e trata mudanças simples como magia negra. Uma revisão quase foi rejeitada porque um pacote nuget adicionou um alvo e adereços: P. Admito que tudo isso é anedótico.

Eu prefiro dizer que o ecossistema .NET ainda não amadureceu a ponto de tomar as decisões em suas próprias mãos, em vez de sempre esperar que a MS entregue tudo para satisfazer a todos.

Como eu disse, está implícito neste problema que melhorar a experiência de edição do MSBuild é algo que apenas o MS pode / deve fazer. Isso dificilmente é o caso.

Se as pessoas se importam tanto, provavelmente já deveriam começar a "consertar" isso. Há mais extensões do VS de código aberto disponíveis (pela Microsoft e outros) para iniciar qualquer esforço desse tipo por um indivíduo comprometido.

Mas eu aplaudo o esforço renovado que estamos falando para melhorar o MSBuild implementando a maioria das ideias que os desenvolvedores gostaram sobre xproj / project.json.

Assim como o WPF, acredito que o MSBuild é uma engrenagem de tecnologia que por acaso definhou por algum tempo (no caso do WPF, ainda é, infelizmente)

Como eu disse, está implícito neste problema que melhorar a experiência de edição do MSBuild é algo que apenas o MS pode / deve fazer. Isso dificilmente é o caso.

Eu normalmente concordaria, exceto no momento em que falamos, a Microsoft está implementando uma revisão massiva da construção do .Net, dos padrões do MSBuild e de como o VS interage com o MSBuild. Se já houve um tempo em que isso estava nas mãos da Microsoft, é agora.

Eu tenho desenvolvido com .NET desde que estava em beta e tenho sido o líder no trabalho que teve que entrar nos detalhes do MSBuild para configurar servidores de CI e tal e sempre tive dificuldade em convencer os outros a seguirem. Como alguém que está principalmente fazendo trabalho de desenvolvimento e de vez em quando modificando e ajustando arquivos de compilação, meu problema sempre foi que há muito tempo entre cada vez que preciso trabalhar com as especificações do MSBuild, então sempre tenho que continuar reaprendendo as mesmas coisas especialmente porque considero a maioria deles pouco intuitiva, prolixa e com falta de documentação e convenções bem estabelecidas. Até mesmo olhar para coisas como tarefas comunitárias que antes eram promissoras agora parecem muito desatualizadas. Como um exemplo recente de um de meus esforços com o MSBuild, que levou mais de 2 dias para funcionar da maneira que eu queria, eu precisava de uma maneira simples de capturar informações de versão do TFS em um arquivo e pacote junto com um aplicativo da web . A mesma tarefa teria me levado minutos em NodeJS / Git e teria se sentido muito menos como um hack. Eu poderia ter surgido com uma solução mais rápida e elegante, codificando-a em C # também, se o resultado fosse fácil de conectar ao pipeline de compilação. Para outras coisas orientadas a processos envolvidas em empacotamento e implantação, aprendi a confiar mais em scripts como o Powershell, uma vez que eles se fundem melhor, são muito mais capazes do que o MSBuild nesse aspecto.

Depois de passar algum tempo nos últimos anos trabalhando mais em JavaScript e TypeScript, tanto no lado do cliente quanto no Node, desenvolvi um profundo apreço pela simplicidade do modelo em que a mesma linguagem pode ser usada para compilações e código de aplicativo. No mundo do Node, não é necessário nenhum esforço para convencer os desenvolvedores a mexer e explorar o processo de construção e acredito que é por isso que há uma explosão de projetos relacionados a processos maduros e altamente ergonômicos no NPM.

Em última análise, o que eu acho que é necessário é que o Visual Studio e talvez o MSBuild torne mais fácil aceitar comandos de compilação alternativos. Acho que o VS Code está fazendo um ótimo trabalho nessa frente, mas ainda há pontos problemáticos que acho que estão relacionados principalmente à gravidade do Visual Studio e do MSBuild. Um exemplo seria o estado atual de desenvolvimento do F #. A experiência de edição para F # no VS é boa, mas vá para a definição e recursos como esse não funcionam corretamente entre projetos baseados em csproj e fsproj e mesmo no VS Code com Ionide, um arquivo fsproj é necessário para obter o intellisense. Até agora, não consigo encontrar nenhuma referência sobre como as últimas alterações de ferramentas anunciadas afetam os projetos F # com relação a inclusões de arquivo curinga e elementos PackageReference. Enquanto isso, ficaria feliz em abandonar completamente o fsproj por uma solução como o FAKE, contanto que outros desenvolvedores do Visual Studio ainda pudessem desenvolver o projeto com o suporte intellisense adequado que eles esperariam.

Minha reclamação com os arquivos MSBuild e csproj em geral é que parece uma tecnologia como o SQL, que ficou presa no passado e parece que não há esperança em qualquer mudança significativa além de suas aspirações originais. Talvez isso mude agora, mas depois de anos fazendo sugestões para melhorar coisas como caminho relativo do projeto para dependências, redundância de referência de pacote nuget, ordenação de item não alfa, pareamento de arquivo complexo (ex. Xsd, cs, code behind, designer.cs), falta de suporte a curingas e uma história de extensibilidade excessivamente complexa. Tive a mesma sensação que acabei tendo com WebForms, Silverlight e WPF de que ninguém do outro lado realmente se importava em avançar mais e apenas em manter o que já estava lá.

Acho que a sugestão de criar um modelo de objeto limpo em torno de projetos ou um conjunto de APIs que o Visual Studio usaria para ler e entender um projeto, modificá-lo e, por fim, criá-lo seria ótimo. Se pudesse ser mantido de uma forma que pudesse ser extensível para permitir outros formatos de projeto, então, ótimo. Se esses formatos não estivessem restritos a diferentes tipos de serialização do mesmo modelo de objeto, mas, em vez disso, permitissem implementações de compilação alternativas, como CAKE, FAKE ou algo desenvolvido internamente para ser conectado, isso seria excelente. Para aqueles que trabalharam em Node.js, eu gostaria de algo tão onipresente, simples e poderoso como scripts npm para que qualquer projeto possa ser construído, não chamando necessariamente msbuild, mas invocando a compilação padrão para esse projeto, que pode ou não seja MSBuild.

Assim como não houve necessidade de fornecer uma experiência de edição incrível para arquivos de configuração .net durante anos e anos.

Sim ... falando nisso. Essa é outra tecnologia que continua a sofrer do mesmo problema fundamental que estamos discutindo aqui: DOM mapeado baseado em XML (fraco / sem esquema) vs. serialização baseada em POCO (esquema forte).

Quer dizer, editar essa coisa não é ciência de foguetes: p

Haha ... quer apostar? 😛 Especialmente em comparação com as experiências modernas e ESPECIALMENTE em comparação com as experiências de edição existentes no Visual Studio com Xaml (que é o que eu continuo voltando como o modelo ideal aqui).

Sei que você não acha que isso seja um grande negócio @kzu, já que obviamente você tem um grande controle sobre isso, tendo criado o que eu sinto que são alguns dos melhores arquivos MSBuild formatados / criados que eu já vi pessoalmente (olhe essas belezas! Basta você olhar para eles !!!). Não seria ótimo se todos fossem tão bons e fluentes com o MSBuild? Em última análise, é isso que buscamos aqui.

Se as pessoas se importam tanto, provavelmente já deveriam começar a "consertar" isso.

É isso que estamos tentando fazer aqui. :) No entanto, conforme discutido acima, o modelo atual está enraizado na API XML e é quase impossível de modificar sem alterações em massa, abrangendo (e certamente interrompendo). Portanto, até conseguirmos a adesão dos detentores do projeto aqui para refletir a vontade / desejo da comunidade em geral, o melhor curso de ação que temos aqui é falar sobre isso na esperança de que eles o façam. 👼

Oh Deus. Acabei de ler isso.

Preciso de mais café.

Tudo era incrível no .NET Core e agora estamos de volta a essa porcaria. Muito triste!
- em nome de Trump.

Algumas pessoas querem apenas manter as coisas complexas. Não, eles não são - tenho usado o MSBuild extensivamente nos últimos anos, mas tento convencer outra pessoa do meu escritório - você fracassará totalmente porque:

1. É muito mais complexo do que o necessário. É um camelo com um laser gigante amarrado nas costas - muito extensível, mas quem precisa disso ?!
2. Ilegível.
3. Você realmente precisa de um engenheiro de construção para realizar o trabalho avançado de maneira adequada. Vocês não acham que isso deve ser feito por desenvolvedores sem investir muito tempo?
4. Você está esperando que as pessoas NÃO mexam nos arquivos .csproj (veja os tutoriais do VS para editar .csproj). Daí a coisa do camelo. Supõe-se que ele o carregue, mas quando não o faz - use este laser para se ajudar no deserto.
5. Eu orientei alguns estagiários diretamente no .NET Core, já que o estamos usando intensamente em nossa organização. Ontem eu tive que pedir a eles para migrar e dar uma olhada no MSBuild (considere que eles foram ensinados a adicionar / remover pacotes e fazer alterações diretamente em project.json. Nada de IU.). Você realmente não quer saber suas reações.

Tl; Dr: Não sou apenas a favor da sintaxe json. Eu aposto em tornar as coisas simples. Esta filosofia de "Simplesmente funciona, mas quando não funciona - compre um livro". Não está funcionando bem.

Haha @YehudahA você pode certamente receberá o downvote como habilidosa e

Falando em votos positivos, este problema agora está em 103, mais 9 corações agora. Para o contexto, os problemas mais próximos para qualquer categoria são 9 votos positivos e 1 coração , respectivamente.

Também quero enviar uma mensagem para a ótima sugestão de @gulshan em https://github.com/Microsoft/msbuild/issues/1289. Por favor, tome um segundo e forneça feedback e / ou um voto positivo também.

Obrigado a todos por seu apoio e diálogo contínuos para melhorar o MSBuild e torná-lo a solução de compilação confiável que todos gostaríamos de ver e usar. 👍

@Grinderofl Deixe-me

O MSBuild é o sistema de projeto padrão para todo o ecossistema no momento. A Microsoft tem uma quantidade finita de desenvolvedores trabalhando em cada tecnologia / pilha. Se eles dividirem o sistema do projeto em dois, agora terão 2 equipes conduzindo os esforços para melhorar o sistema de compilação de duas maneiras diferentes.

Mas isso não é tudo! Agora seus clientes estão chateados porque agora você tem dois sistemas de construção e eles precisam aprender outro.

Você acaba com um esforço menos focado e irrita os clientes. Portanto, a menos que eles estejam criando o futuro do Build System, voltar ao MSBuild é, na verdade, uma ideia bastante sensata. project.json foi criado quando DNX foi inventado. O foco não era o sistema de construção, mas sim ... jogue ideias na parede e veja o que pega.

Se eles mantivessem project.json , eles teriam terminado com a situação que descrevi acima. Clientes irritados e esforços desfocados em dois sistemas em vez de um.

Ter um csproj mal formatado com o MSBuild é simplesmente ... horrível! O que havia de errado em ter project.json que era usado pelas ferramentas dotnet como publish ?? Usar XML para começar é [..] para algo que deve ser legível por humanos (sim, os arquivos de projeto DEVEM ser legíveis por humanos!).

Ter um project.json mal formatado é igualmente horrível. Você deu uma olhada no novo arquivo csproj limpo? Embora ainda haja coisas que gostaria de alterar (por exemplo, versão como um atributo em vez de um elemento), acho que é muito mais limpo e enxuto.

E, honestamente, XML é tão legível e editável por humanos quanto JSON. Concordo que os arquivos de projeto devem ser legíveis por humanos - e isso é o que são os arquivos de projeto MSBuild.

E o project.json tinha outras desvantagens também (nenhuma maneira de comentar, sem vírgulas finais).

Embora a abordagem "Format Agnostic" seja provavelmente a solução mais flexível, não acho que seja muito viável. Isso levaria a fraturar o ecossistema ainda mais com benefícios duvidosos e aumentaria enormemente a complexidade de todo o sistema. "Como você faz XYZ?"

Permanecer unificado no sistema MSBuild é a melhor escolha que eles podem fazer. E, francamente, não é tão terrível quanto muitas vozes vocais querem fazer parecer. Especialmente com o processo de limpeza que a Microsoft está fazendo.

@MartinJohns Espero que você aprecie a ironia que eu aprecio de ter você declarando que haverá 50 sabores de sistemas de construção e, em seguida, declarar que nunca é tão ruim quanto as pessoas fazem

Para ter certeza aqui, a ideia é ter um modelo baseado em CLR que pode ser descrito em vários formatos.

Além disso, estou começando a enfrentar o desafio de @ jnm2 aqui de escrever uma prova de conceito muito simples para demonstrar a ideia. Com toda a energia que já gastei neste repo, sinto que poderia ter feito isso em espadas dez vezes agora. 😛 Não quero perder muito tempo com isso pelo motivo que afirma @MaximRouiller (e mais). Vamos ver onde a tarde me leva (no que eu me meti agora ???).

@MartinJohns

Embora ainda haja coisas que eu gostaria de mudar (por exemplo, versão como um atributo em vez de um elemento)

Está acontecendo. Você pode ver aqui onde estamos atualizando os modelos de projeto do VS para tirar proveito disso: dotnet / sdk # 394 Também estamos trabalhando em uma limpeza adicional do formato .csproj .

Para @Mike-EEE e outros que desejam experimentar o suporte a um formato de arquivo de projeto totalmente diferente no MSBuild, o lugar para começar a procurar é provavelmente nas APIs de construção do

Obrigado @dsplaisted pelo ponteiro. Na verdade, descobrimos isso anteriormente neste segmento (agora bastante longo!), Ao discutir a viabilidade de usar POCOs em vez de XML. XML é de fato fortemente acoplado a classes em todas as bibliotecas do MSBuild, mesmo sendo usado como propriedades completas, como o Project.Xml .

(Você consegue imaginar uma propriedade Project.Json ? Os dados não devem ser fortemente acoplados ao objeto serializado que eles descrevem. É isso que pretendemos resolver.)

Para sublinhar a pergunta aqui, a ideia seria _não_ introduzir um novo formato, mas simplesmente torná-lo de forma que propriedades como Project.Xml desapareçam, e o XML que é lido simplesmente serializará a entidade Projeto na memória , junto com todas as suas instâncias filhas. Esperançosamente, isso faz sentido.

Depois de fazer isso funcionar para um formato (XML), você também pode fazer com que funcione para outros formatos. Em essência, o arquivo de projeto se torna uma entidade Project serializada e pode ser descrito em qualquer formato compatível e, ao fazer isso, produzirá qualquer mágica de ferramenta já criada para esse formato.

OK, eu levei algum tempo para desenvolver um modelo básico de SUUUUUUOOOOOPER no que estou pensando aqui. Você pode achar aquilo aqui:
https://github.com/Mike-EEE/Stash/tree/master/MsftBuild.Model

Coloquei os projeto aqui e os POCOs de processamento aqui.

Descrevi um possível arquivo de projeto aqui e um possível arquivo de processamento aqui. Usei o template do

O projeto em que cheguei (e de forma alguma estou sugerindo, apenas esboçando aqui) torna o arquivo Project um ServiceLocator , de modo que suas "propriedades" (ou serviços) não são fortemente definido, o que o torna super flexível. Cabe ao processador obter os dados de que precisa ( conforme demonstrado aqui ).

_ (Novamente, isso não é de forma alguma uma sugestão final em nenhum sentido. Apenas fazendo alguns esboços.) _

Desenha as discussões / decisões à parte, no final o que é importante é:

1. Um elemento Project POCO é definido em um formato serializado. ( Exemplo )
2. Esse Project é então lido na memória. (Não definido nesta amostra)
3. Esse projeto é então enviado para um Processor de algum tipo. ( Exemplo )

Eu também descrevi isso em Xaml (como você provavelmente sabe, eu sou um fã) para mostrar algumas coisas legais que você pode fazer neste formato específico, como fornecer uma versão de um arquivo externo e também use um para consultar os arquivos necessários para compilar .

Finalmente, para mostrar a "mágica das ferramentas" de que continuo falando e o motivo pelo qual sou tão louco por Xaml / POCO, aqui está uma captura de tela do cursor do mouse no nível mínimo de registro de um dos elementos:

Você pode ver que há uma lista suspensa, caixas de seleção e tudo mais, sem precisar fazer nada, apenas definir um POCO no arquivo Xaml. _Esta é realmente uma experiência "iluminada "_, IMO. Além disso, no Xaml, há suporte a plug-ins para os editores usados ​​no painel de propriedades, portanto, poderíamos torná-lo ainda mais personalizável / legal se quiséssemos. É esse tipo de poder / paradigma que acho que devemos nos esforçar para alcançar - mas em qualquer formato possível e não apenas no Xaml .

Espero que isso esclareça meu lado / posição aqui. Mas tenho certeza de que isso criará mais perguntas do que não. 😄

Haha @djanosik sim, eu deveria ter colocado um aviso sobre isso, já que Xaml é definitivamente mais falante do que JSON (ou XML). Como mencionei em # 1289, existem novos sabores de Xaml surgindo que tratam desse problema.

O .csproj apagado é muito mais legível e amigável para humanos.

Esta é uma afirmação muito subjetiva e realmente está no cerne do problema que estamos tentando resolver aqui. Enquanto você vê o Xaml como "menos" amigável aos humanos, eu e muitos outros amamos sua expressividade e poder.

No entanto, no final, o que é importante aqui não é o detalhamento e / ou tagarelice, mas os _recursos e integração de ferramentas_ que é possível com uma abordagem baseada em POCO, que Xaml faz um ótimo trabalho e espero que a captura de tela e uso da captura de MarkupExtension s. Você simplesmente não pode alcançar tal poder com XML ou JSON.

Novamente, a ideia é, eventualmente, capturar esses conceitos e torná-los disponíveis em _qualquer_ formato. Eu uso o Xaml, pois é claro que ele faz isso fora da caixa, sem muito esforço de minha parte para demonstrar. Sou preguiçoso, o que posso dizer. :)

Haha ... OMG, estou morrendo aqui. OK. Fui em frente e criei para você um arquivo Project.json, @djanosik :
https://github.com/Mike-EEE/Stash/blob/master/MsftBuild.Model/MsftBuild.SampleProject/Project.json

(E fiz isso simplesmente atualizando o POCO descrito pelo

Então, novamente: não é a tagarelice ou esquema (teórico) que é usado aqui que é importante. O que é importante é que este arquivo e este arquivo _both_ descrevem este POCO . Faz sentido?

Ah, agora @djanosik, você está provando que a recompensa pelo trabalho árduo é mais trabalho árduo. :) Neste caso, estamos tratando de alguns itens aqui. Na verdade, isso começou em @ # 1289 quando @ jnm2 corretamente me lembrou de uma discussão em https://github.com/aspnet/Home/issues/1433 que o processamento deve ser separado dos dados. Portanto, este POC está realmente mostrando duas coisas:

1. Modelagem baseada em POCO
2. Separação de interesses entre processamento e dados / definição.

Agora, para responder à sua pergunta, criar uma nova tarefa de compilação personalizada seria semelhante a implementar ITask como fiz para BuildProcessor aqui . Neste caso, o BuildProcessor não possui nenhuma propriedade, mas se tivesse, seria descrito / definido no arquivo de definição do

Novamente, esta é apenas uma ideia esboçada, e nada definitivo / oficial, para ajudar a concretizar a ideia do que estou interessado em resolver.

Ah, obrigado, fico feliz que haja algum empurrão para essa ideia.

Eu estava mencionando o HOCON porque vi alguns comentários sobre web / app.config que também são difíceis de lidar, especialmente ao implantar em vários destinos com alguma configuração específica.

Como uma ideia simples, se o núcleo .Net precisar mudar para o uso de arquivos .csproj para o IDE
e a única maneira de fazer alterações sem o IDE é por meio de uma ferramenta (o que parece horrível)

Por que não ter uma ferramenta / algo parte da ferramenta dotnet que lê um arquivo project.json e gera o arquivo .csproj como parte do processo de construção
então, em vez de project.json.lock, que é uma espécie de versão postbuild de project.json, ele sai diretamente para um arquivo .csproj

É um pouco de trabalho extra, mas provavelmente vale a pena

Tudo o que vejo são pessoas discutindo sobre o formato json só porque nunca o usaram e porque ele conhece o msbuild de cima a baixo.

<NuGetPack File="%(NSPSTransformed.Identity)" OutputDirectory="$(BuildOutputNuGet)" Properties="Configuration=Release" IncludeReferencedProjects="true" ToolPath="$(nugetToolPath)" />

Alguém está realmente comparando isso 💩 ao project.json?

Tudo o que vejo em cada arquivo csproj sugerido, postado e chamado de fabulous intelisense está cheio de strings mágicas, mesmo para coisas como True e False.

Ironicamente, parece que CSPROJ não é digitado enquanto JSON é digitado.

no lado do project.json:
algumas pessoas inteligentes perceberam que este seria um ótimo formato para o núcleo do asp.net. Até Fowler disse que era seu recurso favorito.
Não se trata do formato ou do intelisense ou dos recursos A e B. trata-se de uma experiência completa.
É digitado, tem intelisense, tem opções de solicitação de http, era muito rápido, muito compreensível, super ultra duper hiperdicobrível, e se você acha que csproj também é, você não o UTILIZOU, apenas comentando baseado em olhar para o arquivo em alguns github repo.

Se você for contra, diga-nos que o usou e tentou por pelo menos uma semana.

mas
aparentemente, ele tem algumas limitações que não estão presentes no csproj. (e esta pode ser uma razão muito boa / válida para abandonar seu apoio agora)

Sou totalmente favorável ao csproj e confio nas pessoas por trás do produto.
Apenas, dê algum crédito e pergunte-se "por que, se project.json não é bom que csproj, as pessoas inteligentes por trás do asp.net investem e fazem um sistema que todos (que o usaram) se apaixonem à primeira vista?"

Importações? Alvos? Propriedades? ToolPath? essas palavras são todas sem sentido e é por isso que você não a vê mencionada em project.json, enquanto target framework , dependencies , includes (dicas de ferramentas que sugerem suporte a globbing padrões, uma string ou um array de strings dentro de publishOptions são autoexplicativos.

conclusão: project.json é A-MA-ZING. período. Se você acha que não é, você não o usou. Não se trata do formato do arquivo, mas de muitas coisas sutis que surgiram com a "experiência". Pare de compará-lo através do diff do arquivo. basta escolher um projeto e começar a desenvolvê-lo.

Fato verdadeiro: quando o project.json foi introduzido pela primeira vez, ele não tinha documentação, nenhuma resposta sobre estouro de pilha, nenhuma ajuda real do IDE, mesmo assim todos os desenvolvedores da Web o estavam editando manualmente e estavam muito felizes.
Agora, no csproj, temos documentos, muito histórico, um produto 1.1 estável, especialistas em todo o mundo e, ainda assim, os desenvolvedores da web estão usando uma GUI menos produtiva para fazer alterações no arquivo do projeto e não estão satisfeitos com o csproj.

Para todos os odiadores do project.json: experimente. e aponte exatamente o que há de errado ou ruim nisso.
Para todos os amantes do msbuild: desculpe, há coisas melhores por aí, mesmo que isso signifique que você precise mudar / adaptar.
Para todos os amantes do project.json: ele tem limitações e custos associados. Lide com isso, ter uma coisa é melhor no geral, e você ainda pode sonhar com um futuro melhor.
a todos os odiadores do msbuild: seja vocal sobre seus pontos fracos. as chances são (pelo menos tenha alguma fé) que evolua para algo útil como o project.json foi, não hoje ... mas pode acontecer.

Acho que @ jnm2 está certo. Por mais que eu reclamei sobre a mudança de volta para XML, agora posso ver que era um problema de comunicação. A equipe CLI / MsBuild nos disse "confie em nós, será ótimo", mas eles não forneceram exemplos nem atualizaram os documentos.

IMHO, o novo csproj é ótimo. Estou tendo mais facilidade com isso do que com a sintaxe json, honestamente.

Aqui estão dois (nomes mascarados) arquivos csproj que estou compilando hoje (no VS2017 RC3).

• Estou desenvolvendo em VSCode e VS2017 alternadamente e ao mesmo tempo
• Estou executando via F5 (depuração) e de dotnet run .
• Estou depurando e usando Editar + Continuar
• Estou editando manualmente o arquivo do projeto e o VS2017 está atualizando em tempo real.
• Estou gerando executáveis ​​específicos da plataforma por meio de dotnet publish -r win7-x86 em outros
• Dezenas de arquivos .cs, milhares de linhas.
• Sem GUIDS
• Sem condições malucas

Biblioteca (MyCorp.Lib.csproj)

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

Executável (MyCorp.Connector.Runner.csporj)

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

Acho que todos devemos dar um passo para trás e olhar para o progresso atual do esforço de simplificação e decidir se é bom o suficiente agora, porque eu acho que é.

São pessoas que trabalham.

@AlgorithmsAreCool Muito obrigado pelo feedback, fico feliz que você esteja feliz com o progresso que fizemos. Se eu olhar para trás, quando anunciamos que estávamos mudando de project.json -> csproj para agora, adicionamos _muito_ sobre o antigo csproj:

Projeto:

• Padrões inteligentes. AssemblyName, Default Namespace, etc agora têm padrões razoáveis ​​e não precisam ser especificados por padrão.
• Não há mais GUIDs. :)
• Objetos / alvos específicos de idioma / alvo específicos por meio do atributo Sdk
• Metadados como atributos, então você pode dizer <PackageReference Include="Newtonsoft.Json" Version="9.0.1"/> vez de <PackageReference Include="Newtonsoft.Json"><Version>9.0.1</Version></PackageReference . Isso funciona com todos os itens, não apenas com as referências do pacote.
• Configurações implícitas - por padrão, todos os projetos têm duas configurações; Depurar | AnyCPU e Liberar | AnyCPU com padrões razoáveis. (Observação: atualmente temos 6 configurações no RC, mas 2 por hora já enviamos).
• Suporte de globbing implícito, com um conjunto padrão de globs comuns, para que você não precise especificá-los. Os projetos podem ser substituídos se quiserem
• Referências de projeto simplificadas, sem necessidade de especificar o nome ou metadados GUID
• Gere automaticamente AssemblyInfo, incluindo <AssemblyVersion> e <AssemblyFileVersion> para que agora possam ser baseados nas propriedades do MSBuild.
• Referências transitivas de projeto

Alvejando:

• Nomes TFM amigáveis ​​em <TargetFramework> , então você não precisa especificar <TargetFrameworkIdentifier> ou <TargetFrameworkVersion> .
• Suporte multi-segmentação por meio da propriedade <TargetFrameworks> , de modo que um único projeto possa produzir várias saídas visando várias estruturas / plataformas
• Símbolos de compilação condicional implícita com base na estrutura de destino que você almeja
• Suporte para itens condicionais como referências, pacotes e itens de compilação _e_ faça com que o VS os respeite, então você pode diferenciá-los com base na estrutura de destino.

NuGet:

• <PackageReference /> que permite que você especifique (apenas) suas dependências de pacote de nível superior dentro do csproj junto com suas outras dependências
• Referências de pacote transitivo
• NuGet Restore via msbuild
• Produza um pacote NuGet via msbuild
• Restauração em segundo plano, para que os pacotes sejam restaurados em segundo plano enquanto o projeto está aberto.

Estúdio visual:

• Suporte real para globbing ( **\*.cs , etc) - o VS não expande mais o glob quando você exclui um arquivo, ou adiciona um include quando você adiciona um arquivo já incluído no glob. O VS também seleciona automaticamente a adição de novos arquivos (ou exclusões de arquivos existentes).
• Atualização automática. O VS pegará automaticamente as mudanças do disco quando você trocar de branch ou modificá-lo para outro editor e apenas aplicar as diferenças sem recarregar o projeto
• Edite enquanto estiver aberto. Agora você pode editar o arquivo do projeto enquanto o projeto está aberto e fazer com que o VS selecione as alterações em Salvar.
• Novo nó de dependência (substituição de referências) que mostra pacotes, referências, referências de projeto, SDKs e suas dependências.

Acima está apenas a lista da qual me lembro de cara, tenho certeza de que perdi várias. De qualquer forma, estamos em uma jornada que continuará muito além deste lançamento. Continue enviando comentários!

Dito isso, os problemas reais surgem quando uma construção requer mais do que simplesmente declarar dependências e estar em conformidade com o conjunto de ferramentas padrão do .NET. É aqui que o Gradle brilha

@slorion O que você quer dizer? O novo csproj limpo é construído no msbuild, que é um sistema de construção completo. Não sei muito sobre o Gradle, mas em termos de sistema de compilação, você pode fazer praticamente o que quiser com o msbuild e desenvolver compilações complexas. Essa é uma das razões pelas quais eles mudaram de projetos project.json para (limpar) msbuild.

[Editar] O próximo passo real é substituir * .sln por um arquivo de solução msbuild limpo adequado para coordenar a construção de vários projetos (e isso é realmente o que é feito quando um sln já foi convertido em um arquivo msbuild por baixo do capô. ), mas acredito que eles trarão essa mudança em algum momento após a migração do project.json [/ Edit]

👍 ao excelente trabalho do novo formato .csproj. @davkean e a equipe estiveram impressionantemente ocupados e produtivos no repo CPS e foram uma maravilha de assistir. O novo formato é notável e nada menos que impressionante. (Mas, como sugere @xoofx , é hora de aplicar essa magia ao misterioso e enigmático arquivo .sln. 😉)

Nesse sentido, isso não quer dizer que ainda não possamos fazer grandes melhorias no IDE para promover o objetivo aqui. Em minha opinião, o objetivo do problema é criar uma experiência que permita:

• Pode ser visualizado em um formato de dados desejado (assim como os desenvolvedores .NET podem escolher trabalhar em C # / VB / F #)
• Pode editar manualmente como um campeão (parece que isso está mais perto da realidade agora, ala acima)
• Fácil de usar ferramentas visuais / de design (uma espécie de driver inicial aqui)

Existem dois campos aqui: aqueles que gostam do CLI e ... aqueles que não gostam. :) Ambos os campos devem ser considerados no futuro para criar um paradigma de desenvolvimento de sucesso.

O objetivo de usar um esquema de desenvolvimento baseado em POCO é que o esquema seja gerado automaticamente para você a partir das definições de classe, e as ferramentas do designer "acendem" automaticamente quando direcionadas a ele. Isso torna mais fácil para o desenvolvedor e as ferramentas usarem para o desenvolvimento.

No entanto, estou definitivamente aberto a quaisquer outras idéias e direções inovadoras para atingir esse objetivo. Eu realmente gosto de ler os pensamentos e esforços de @gulshan nos diferentes tópicos para uma notação de objeto diferente. Gradle parece ser o bolo super quente no momento, então talvez haja algo que valha a pena aprender e integrar lá. Talvez algum cruzamento entre seu formato e uma integração de ferramentas visual de @ionoy 's grande trabalho com AmmyUI (imaginar trabalhando com um arquivo VS / MSBuild mas com intellisense monstro em esteróides) é a resposta? Continua. :)

Sou novo em C # e .NET em geral. Ouvir sobre o Core me deixou animado para aprender C #. Iniciei o VS2015 e criei uma solução. Eu imediatamente me senti em casa, e coisas como project.json definitivamente contribuíram para esse sentimento.

Não sou o tipo de desenvolvedor que fica na zona de conforto. Você conhece o tipo: com preguiça / medo de aprender algo novo. Ainda assim, olhar os arquivos .csproj faz minhas células cerebrais cometerem seppuku. Olhando as notas do patch, devo dizer que a equipe fez algumas melhorias interessantes.

Se o suporte do MSBuild estimular as pessoas a migrar projetos legados, contribuindo assim para o sucesso futuro da plataforma, então posso embarcar nele. Mas e se o custo disso estiver assustando novos desenvolvedores? É apenas uma daquelas coisas que me faz pensar: "Deve haver uma maneira melhor". Como padawan, não posso dizer que conheço o caminho, mas mesmo um padawan pode compartilhar sua perspectiva e percepção.

Luke : _Mestre, mover pedras é uma coisa. Isso é totalmente diferente._
Yoda : _Não! Não é diferente! Apenas diferente em sua mente. Você deve desaprender o que aprendeu._
Luke : _Tudo bem, vou tentar._

Eu acho que a desvantagem é que todo o estúdio VS é muito opinativo de qualquer maneira. Sou um desenvolvedor .net desde .net 1.0 em 2003. Sempre odiei o MSBuild, provavelmente principalmente porque, em minha opinião, ele está muito alinhado com o pior da Microsoft conhecido como TFS. Sempre preferi o que era conhecido como a pilha ALT.net do dia. Isso não quer dizer que não tenham existido ótimos produtos na pilha .net como um todo. Provavelmente, a maioria dos Devs tem uma relação de amor / ódio com o VS Studio, assim como a maioria dos Java Devs tem uma relação de amor / ódio com o Eclipse ou IntelliJ.

Pessoalmente, acho que isso está muito claramente retratado nos comentários acima, certamente não existe o ÚNICO caminho certo. Honestamente, qualquer que fosse a decisão, haveria perdedores. Mais uma escolha Brexit / Trump!

Eu realmente gostei do formato Project.json. Achei muito simples de grocar e era fácil de editar à mão.
Mas, dizendo isso de modo geral, gosto do novo formato csproj,

O que não gosto e, especificamente, o problema que tenho agora, é que estou trabalhando no VS 2017 RC, estamos a apenas alguns dias de ser lançado e algumas coisas básicas simplesmente não estão funcionando. Que são um resultado direto da mudança json / csproj e tiveram um impacto direto na minha produtividade.

Estou acostumado a trabalhar com produtos de sistema operacional e entendo os riscos de desenvolver novos softwares em coisas de candidatos a lançamento, mas quando uma notificação sai há algumas semanas, avisa sobre a mudança e as etapas a serem seguidas para se preparar para ela. Mas ainda assim as coisas simplesmente não funcionam
>
dotnet ef
System.IO.FileNotFoundException: Não foi possível encontrar o arquivo 'C: \ Users \ gary \ code \ portal \ src \ DBDummyUIproject.json'.
Nome do arquivo: 'C: \ Users \ gary \ code \ portal \ src \ DBDummyUIproject.json'

Basicamente, tive de ler de uma capa à outra da Internet para encontrar apenas esta postagem
https://github.com/aspnet/Tooling/blob/master/known-issues-vs2017.md

O que me informa que as ferramentas EFcore não funcionarão com o novo formato csproj. No entanto, ainda estamos a apenas alguns dias de um lançamento.

Não é um gemido, da equipe ou da Microsoft. Eu sei que no final do dia, sempre seria uma escolha de hobsons. No entanto, acho que há muito escopo no argumento de dar à comunidade a escolha do formato, em vez de dar a eles uma implementação opinativa, com base no fato de que funciona com o MSbuild, o que está ok se você for usar MSBUILD, mas e se você não for?

Desculpas pela longa caminhada!

@garywoodfine pode estar faltando uma referência à versão msbuld das ferramentas ef em seu csproj (observe o número da versão):

<ItemGroup> <DotNetcl*toolReference Include="Microsoft.EntityFrameworkCore.Tools.DotNet" Version="1.0.0-msbuild3-final" /></ItemGroup>

@dasMulli Obrigado
eu tive
<DotNetcl*toolReference Include = "Microsoft.EntityFrameworkCore.Tools.DotNet" Version = "1.1.0-preview4-final" /> `

Mas agora quando eu tento
<DotNetcl*toolReference Include="Microsoft.EntityFrameworkCore.Tools.DotNet" Version="1.0.0-msbuild3-final" />

Acabei de receber "ef não é reconhecido como um comando interno ou externo"

Eu tentei com os dois pacotes juntos e estou de volta ao erro original

--Editar
Então, agora finalmente estou funcionando, as etapas que eu executei estão, apenas no caso de alguém ter tido esse problema.

Eu removi a referência a
<DotNetcl*toolReference Include = "Microsoft.EntityFrameworkCore.Tools.DotNet" Version = "1.1.0-preview4-final" /> `

Em seguida, fez um dotnet restore no terminal

em seguida, adicionou a referência a
<DotNetcl*toolReference Include="Microsoft.EntityFrameworkCore.Tools.DotNet" Version="1.0.0-msbuild3-final" />

em seguida, fez dotnet restore no terminal

então tentei dotnet ef e tudo começou a funcionar
Obrigado @dasMulli

Estou atrasado para o jogo, mas queria entrar aqui:

Livrar-se do project.json em favor de uma alternativa baseada no MSBuild vai acabar com as ambições da minha empresa atual de oferecer suporte ao .NET em escala. Recentemente, herdei algum trabalho baseado em .NET que precisa ser atualizado e estava muito animado para ver o que mudou no mundo do .NET na última década (eu não uso o .NET ativamente desde 2010 e parei de usar o Windows em 2013). Com a mudança de volta para o Visual Studio, mesmo que haja suporte para Mac, parece improvável que haja interesse em dar suporte às plataformas da Microsoft no futuro.

Em 20 anos, ainda não trabalhei com um desenvolvedor que se importasse um pouco com os arquivos proj estarem em xml ou em algum outro formato.

Apenas alguns entendem o que o arquivo realmente faz ou como alterá-lo para tornar a vida mais fácil ou corrigir problemas. Isso parece trabalho pelo trabalho.

Acreditamos que os projetos de estilo SDK resolvem esse problema tornando os arquivos do projeto concisos. Não temos planos de adicionar novos pontos de extensão aos formatos do projeto neste momento.

Obrigado por todos os comentários e discussão aqui.

@livarcocc - bem, como a equipe do nuget, você não está interessado em manter compatibilidade de recursos ou mesmo paridade. Isso parece uma jogada que só serve para punir a base de usuários que está realmente _interessada_ em coisas como formatos de proj. Eu realmente acho que o feedback para este recurso não foi segregado entre "OMGPREVIEW fanboys", os casuais do arquivo de projeto que compõem a maioria da população de desenvolvedores .net, para quem isso parece uma boa ideia do ponto de vista de superfície (mais simples sempre soa melhor, até que você precise de um recurso que foi cortado) e usuários avançados para os quais um conteúdo implícito e um arquivo de projeto ainda não documentado é um eco de projetos de site da Web e um desastre de compilação e automação iminente.

Você pode pelo menos garantir ou prometer que não seremos forçados a usar esses formatos de projeto de estilo SDK problemáticos e inferiores?

Você pode pelo menos garantir ou prometer que não seremos forçados a usar esses formatos de projeto de estilo SDK problemáticos e inferiores?

De que forma você acredita que os projetos estilo SDK são inferiores?

Por favor, indique qualquer coisa não factual. É assim que parece do lado de fora.

• Eles requerem um nuget de estilo de referência de pacote. Isso significa perder coisas úteis do pacote, como adicionar arquivos a um projeto como parte de um pacote (privado), ou fornecer transformações de configuração xdt simples ou executar um script do PowerShell para cobrir todas as outras lacunas possíveis. Também significa não saber quais dependências realmente serão incluídas até que o projeto seja construído e a saída seja inspecionada. Não consigo fazer um pacote privado que seja tão útil para minha equipe com o pacote ref quanto possível com a configuração do pacote.

• não há uma lista explícita de coisas a serem incluídas na compilação.

  • Arquivos perdidos eram uma dor de cabeça com projetos de sites, projetos de aplicativos da web consertaram isso, mas o SDK traz de volta esse indeterminismo para todos os tipos de projetos. As ferramentas que criam arquivos ou pastas extras no sistema de arquivos do projeto precisam ser limpas depois, os hábitos de desenvolvimento / sistema de arquivos desleixados criam mais problemas do que antes, e um dos meus favoritos pessoais vssscc e vssspc arquivos de origem visual vestigial segura ficam ainda mais firmes no controle de versão .

  • inspecionar projetos em bases de código não pode ser feito olhando para o arquivo proj, agora os arquivos constituintes a serem incluídos (quais?) precisam ser baixados. Esperançosamente, VCS ou FS ou o usuário não deu um grito e perdeu um arquivo, porque o projeto não saberá a menos que seja compilado.

  • automatizar algumas mudanças em projetos é significativamente mais difícil pelos mesmos motivos da inspeção, mas a escassez de padrões e tão poucos deles se atrevem a ser documentados - torna o retrabalho de qualquer ferramenta existente uma sessão de perda de tempo.

A história desse formato parece ser a recuperação do momento A-ha quando todos (principalmente) perceberam que o json é ótimo para troca de dados, mas horrível para configuração. Em vez de aprender essa lição, você seguiu em frente quando não era necessário. Não precisava ser feito, há outras coisas que precisam de modernização (arquivos sln, suporte mais fácil para wcf rest, etc.)

Esperançosamente, o ímpeto não foi inspirado por declarações como "minha empresa não vai adotar / abandonar as dobradiças netcore em um formato de projeto" porque são declarações vazias e idiotas. Qualquer um que se mantenha fiel a isso merece o que recebe disso e de outras escolhas idiotas.

Isso é o que posso reunir antes do café da manhã no meu telefone e posso obter algumas edições tipográficas ou de formatação quando consigo ver mais de um parágrafo por vez.

@StingyJack Partes disso não me https://docs.microsoft.com/en-us/nuget/consume-packages/package-references-in -project-files # enable -lock-file

não há uma lista explícita de coisas a serem incluídas na compilação.

Do lado da produção ou do consumo? Ao criar pacotes, é explícito, exceto para a montagem única construída.

inspecionar projetos em bases de código não pode ser feito olhando para o arquivo proj, agora os arquivos constituintes a serem incluídos (quais?) precisam ser baixados

Este é um alívio para aqueles com conflitos de mesclagem frequentes que não podem esperar para colocar o restante de seus projetos no formato csproj mais recente. Ter que ser explícito sempre pareceu uma duplicação por causa de quão básicas as inclusões são.

automatizar algumas mudanças em projetos é significativamente mais difícil pelos mesmos motivos da inspeção, mas a escassez de padrões e tão poucos deles se atrevem a ser documentados - torna o retrabalho de qualquer ferramenta existente uma sessão de perda de tempo.

Muitas coisas sempre estiveram implícitas e idiossincráticas. O SDK mais limpo empurra isso ainda mais no mesmo caminho. Acho que é isso que https://github.com/daveaglick/Buildalyzer resolve.

Apenas para pular e ecoar alguns dos comentários:

não há uma lista explícita de coisas a serem incluídas na compilação.

Do lado da produção ou do consumo? Ao criar pacotes, é explícito, exceto para a montagem única construída.

Já faz algum tempo desde que olhei para o novo formato do SDK, mas acredito que seja do lado do consumo; considere um projeto Layout semelhante ao seguinte:

└───Project A.cs B.cs Project.csproj

Com base em minhas lembranças, Project.csproj tentará proveitosamente incluir tudo em si mesmo como parte do formato do projeto. Isso é ruim pelos motivos que @StingyJack mencionou acima.

A natureza explícita garante que o sistema de compilação está fazendo o que o desenvolvedor pediu, não o que foi "encontrado de forma útil". É muito possível que um desenvolvedor tenha esquecido de fazer o check-in de um arquivo de origem e, a menos que você seja explícito, pode muito bem resultar em uma falha de tempo de execução ao invés de uma versão de construção. Considere uma biblioteca de classes que utiliza Dependency Injection / IoC na qual as classes contidas em B.cs são consumidas. Se um desenvolvedor se esquece de confirmar B.cs sob um modelo implícito, isso não é descoberto até o tempo de execução (esperançosamente em testes internos, mas de acordo com Murphy em um local do cliente, com certeza).

Existem outros motivos para ter arquivos estranhos em uma subpasta que você explicitamente não deseja incluir. Eu sei com certeza que em nossa grande base de código há lugares onde isso é realmente intencional. Considere este padrão:

└───MyClassLibrary A.cs ATests.cs Implementation.csproj UnitTests.csproj

Neste caso, você deseja que A.cs seja incluído SOMENTE em Implementation.csproj , enquanto você deseja que ATests.cs seja incluído SOMENTE em UnitTests.csproj . Você pode argumentar sobre os méritos de colocar tudo isso em uma única pasta de código-fonte (eu sei que tentei), mas essa é a realidade para muitas das grandes empresas de desenvolvimento. É difícil conseguir a adesão das partes interessadas para refatorar projetos que anteriormente "funcionavam".

inspecionar projetos em bases de código não pode ser feito olhando para o arquivo proj, agora os arquivos constituintes a serem incluídos (quais?) precisam ser baixados

Este é um alívio para aqueles com conflitos de mesclagem frequentes que não podem esperar para colocar o restante de seus projetos no formato csproj mais recente. Ter que ser explícito sempre pareceu uma duplicação por causa de quão básicas as inclusões são.

Eu pegaria o lado oposto desse argumento. Nós mantemos 16 ramos de nossa base de código (sim, 16 ...). Embora na superfície eu concorde com você devido ao número de conflitos de mesclagem, há coisas que podem e devem ser feitas para tentar minimizar isso. Para começar, é útil garantir que o formato do projeto seja classificado em uma questão determinística (decidimos pela quase alfabetização). Eu concordo que ter que escrever ferramentas para dar suporte a isso não é divertido, e você pode ver que meu GitHub está cheio de ferramentas para fazer isso, mas a realidade para nós (e outros Build Masters com quem conversei em setores semelhantes) é que é apenas parte do curso.

A capacidade de diferenciar arquivos de projeto rapidamente entre ramificações é crítica para entender o que está e o que não está chegando aos binários finais. Qualquer coisa que possa misturar a saída (adicionando "indeterminismo") é considerado um defeito do mundo DevOps.

Se você gosta da manutenção manual de todos os arquivos .cs, pode colocar <EnableDefaultCompileItems>false</EnableDefaultCompileItems> em Directory.Build.props ou em um csproj. <EnableDefaultItems>false</EnableDefaultItems> também pode ser interessante para você. Consulte (https://docs.microsoft.com/en-us/dotnet/core/tools/csproj#default-compilation-includes-in-net-core-projects). Os padrões são adequados para a maioria dos projetos e você pode substituí-los se eles não forem adequados para o seu projeto.

Quão comum é o problema de esquecer de adicionar um arquivo de origem ao controle de origem (e sem falhar o CI)? Novos arquivos aparecem com destaque usando Team Explorer (Git ou TFVC) ou VS Code ou git da CLI (posh-git).

A capacidade de diferenciar pastas rapidamente entre ramos usando o controle de origem é poderosa. É mais completo do que comparar arquivos csproj, pela minha experiência, e a interface do usuário diff permite que você vá direto para as alterações em qualquer um dos arquivos. Os arquivos são o ponto de partida, a fonte definitiva da verdade.

Quão comum é o problema de esquecer de adicionar um arquivo de origem ao controle de origem (e sem falhar o CI)? Novos arquivos aparecem com destaque usando Team Explorer (Git ou TFVC) ou VS Code ou git da CLI (posh-git).

Pelo menos uma vez por semana internamente. Temos cerca de 70 desenvolvedores com média de 200 commits por semana, o tamanho médio dos commits é de 3 arquivos CSPROJ +/- 20 arquivos CS, a maioria são alterações em arquivos existentes com algumas adições espalhadas. FWIW estamos usando o Subversion, mas duvido que mude o VCS realmente ajudaria (já usamos Ankh, que fornece o overly). Até mesmo seus melhores desenvolvedores absolutos (seus desenvolvedores 10x) ocasionalmente cometerão um erro. É inevitável nesta escala e taxa de mudança.

YMMV; aparentemente isso não acontece com você, eu gostaria de estar lá (mais do que você pode imaginar).

A capacidade de diferenciar pastas rapidamente entre ramos usando o controle de origem é poderosa, mais completa do que comparar arquivos csproj em minha experiência. Os arquivos são o ponto de partida, a fonte definitiva da verdade.

Não discordamos, no entanto, a escala em que isso ocorre é muito maior do que a maioria das ferramentas de diffing respondem razoavelmente rapidamente, nossos ramos são aproximadamente 670.000 Arquivos 60.400 Pastas

Temos ~ 5.800 arquivos CSPROJ, executar diffs rapidamente no nível do arquivo CSPROJ é muito mais eficiente e temos grandes quantidades de ferramentas automatizadas (ambos Commit Hooks e uma ferramenta semelhante ao SapFix (nós o chamamos de Tattler)) com o formato estruturado e determinístico dos arquivos CSPROJ é um grande benefício, de modo que capturamos a maioria dessas falhas logo no início do processo.

Como @StingyJack menciona, existem outros lugares onde a funcionalidade seria muito útil, por exemplo, isso me atinge diretamente:

Não precisava ser feito, há outras coisas que precisam de modernização (arquivos sln, suporte mais fácil para wcf rest, etc.)

E FWIW, você pode querer dar uma olhada nesta ideia fechada: https://github.com/dotnet/cli/issues/12858 Estou trabalhando no código aberto de nosso ferramental que faz algo semelhante @StingyJack parece que você se beneficiaria com isso (mesmo barco você e eu no rio Styx).

Se você gosta da manutenção manual de todos os arquivos .cs, pode colocar <EnableDefaultCompileItems>false</EnableDefaultCompileItems> em Directory.Build.props ou em um csproj.

Obrigado, estaremos habilitando isso em breve. Hoje não usamos o novo estilo de Formato de Projeto (principalmente porque não temos muito .NET Core), mas se tudo correr como planejado, tenho certeza de que precisaremos dele mais cedo ou mais tarde.

@aolszowka Temos cerca de 60 desenvolvedores, além de vários consultores, e _nunca_ vi um caso em que um arquivo de origem ausente passou por CI (sem mencionar a compilação). A configuração que você descreve parece absolutamente horrível :) Como no mundo pode um arquivo de origem _ em falta_ passar CI? Eu entendo que teoricamente, em alguns casos, a reflexão sobre os tipos em um assembly pode ser compilada sem erros (embora mesmo isso deva ser extremamente raro), mas o que isso diz sobre a configuração do CI se não puder capturar coisas básicas como código-fonte ausente?

Para nós (tendo quase 200 repositórios em nosso github org principal), o novo formato de projeto e, especialmente, as inclusões e referências de pacote implícitas (morte de packages.config! :) tem sido uma vantagem _huge_. Anteriormente, desenvolvemos nossa própria pequena ferramenta hacky para lidar com conflitos de mesclagem porque perdíamos muito tempo fazendo isso manualmente, mas desde que começamos a usar o novo formato de projeto, quase nunca precisamos dele.

Como no mundo um arquivo de origem ausente pode passar o CI?

Hoje não; porque você tem que incluir explicitamente o arquivo (esse é o ponto de toda a conversa e o exemplo acima). Portanto, ele começa em CI.

A proposta é remover essa funcionalidade.

Configuração de CI, se não puder capturar coisas básicas como código-fonte ausente

Estamos totalmente de acordo, e é por isso que utilizaremos o <EnableDefaultCompileItems>false</EnableDefaultCompileItems> explícito mencionado acima. 👍

Provavelmente foi adicionado para oferecer suporte a um cenário semelhante.

Anteriormente, desenvolvemos nossa própria pequena ferramenta hacky para lidar com conflitos de mesclagem porque perdíamos muito tempo fazendo isso manualmente, mas desde que começamos a usar o novo formato de projeto, quase nunca precisamos dele.

Parece que foi descontinuado pelo uso de PackageReference ; anteriormente tínhamos uma ferramenta semelhante à sua para classificar package.config maneira determinística, como você fez. Dito isso, você ainda encontra o mesmo problema hoje, e é por isso que nosso novo conjunto de ferramentas simplesmente impõe que PackageReference sejam classificados de maneira determinística (em ordem alfabética pelo atributo Include ).

O mesmo problema existe hoje para praticamente qualquer atributo. Para os nossos desenvolvedores, é mais doloroso lidar com <Compile> , <ProjectReference> , <PackageReference> tags, pois elas têm altas taxas de mudança para nós, portanto, impomos uma ordem determinística para fornecer as ferramentas de mesclagem uma chance de lutar pela solução correta.

Suponho que seja isso o que você quer dizer quando diz:

quase nunca precisamos disso.

Eu estaria interessado em saber que outros casos difíceis você encontra; parece que não estamos sozinhos.

@petertiedemann - tenha em mente que não apenas arquivos faltando, mas também arquivos extras.

Este é um alívio para aqueles com conflitos de mesclagem frequentes que não podem esperar para colocar o restante de seus projetos no formato csproj mais recente. Ter que ser explícito sempre pareceu uma duplicação por causa de quão básicas as inclusões são.

@ jnm2 - Talvez a solução para isso tivesse sido ordenar de forma confiável a maior parte do conteúdo do arquivo de projeto, como deveria ser feito com todos os outros arquivos sem dados gerados por computador, para que as alterações não aparecessem aleatoriamente no arquivo. Isso provavelmente eliminaria muito da angústia, permitindo que a maioria das ferramentas de mesclagem manipulasse isso automaticamente e teria sido uma correção mais simples. No entanto, isso por si só não teria ajudado na fusão e comparação das ferramentas construídas no IDE de primeira linha do mundo, que alcançaram um novo nível de baixa qualidade.

Todos os dias, preciso fazer mais com menos. Encontrar e corrigir um padrão inválido que foi repetido em centenas de projetos é mais difícil sem o manifesto do arquivo e com tantos padrões ainda não documentados .

Re: pacotes, quero dizer que agora posso fazer um pacote apenas dll, mas não posso mais fazer um pacote que os colegas de trabalho possam adicionar que também cuidará da configuração do projeto de consumo, ou adicionar arquivos CS ou TT ao projeto. Tudo isso agora deve ser feito manualmente.

Como no mundo um arquivo de origem ausente pode passar o CI?

Hoje não; porque você tem que incluir explicitamente o arquivo (esse é o ponto de toda a conversa e o exemplo acima). Portanto, ele começa em CI.

A proposta é remover essa funcionalidade.

Configuração de CI, se não puder capturar coisas básicas como código-fonte ausente

Estamos totalmente de acordo, e é por isso que utilizaremos o <EnableDefaultCompileItems>false</EnableDefaultCompileItems> explícito mencionado acima. 👍

@aolszowka Desculpe se não fui claro. Já estamos usando as inclusões implícitas e nunca encontramos problemas semelhantes (como mencionei, vemos as inclusões _implícitas._ como uma grande melhoria de produtividade em relação às _explícitas_). Meu ponto é que, _dado_ implícito inclui, como você pode fazer com que seu IC perca algo assim, exceto em alguns cenários muito exóticos? Parece que no caso de 90 +% você simplesmente terá um erro de tipo ausente em algum lugar e não conseguirá compilar. Se você estiver usando reflexão / DI automatizado, acho que pode ser compilado, mas ficaria muito preocupado se um teste não detectasse o problema.

Parece que foi descontinuado pelo uso de PackageReference ; anteriormente tínhamos uma ferramenta semelhante à sua para classificar package.config maneira determinística, como você fez. Dito isso, você ainda encontra o mesmo problema hoje, e é por isso que nosso novo conjunto de ferramentas simplesmente impõe que PackageReference sejam classificados de maneira determinística (em ordem alfabética pelo atributo Include ).

Na verdade, raramente temos esse problema hoje, porque agora você só precisa lidar com a referência do pacote, e não com as entradas duplicadas no arquivo csproj. Eu concordo em mantê-lo organizado.

Nossos arquivos de projeto estão quase vazios, na verdade. Temos um arquivo de projeto compartilhado que importamos que contém coisas como copyrights e configuração de namespace, e o resto apenas deixamos para as inclusões / comportamento padrão. Um arquivo de projeto típico tem cerca de 20-30 linhas.

Talvez a solução para isso fosse ordenar de maneira confiável a maior parte do conteúdo do arquivo de projeto, como deveria ser feito com todos os outros arquivos não-dados gerados por computador

Para a maioria dos projetos, as pessoas querem deixar para trás a ideia de que um csproj é um arquivo gerado por computador.

e com tantos padrões ainda não documentados.

Existem padrões não documentados? O link que dei anteriormente parecia muito completo na área que li.

como você pode fazer seu IC perder algo assim, exceto em alguns cenários muito exóticos? Parece que no caso de 90 +% você simplesmente terá um erro de tipo ausente em algum lugar e não conseguirá compilar.

Se você estiver usando reflexão / DI automatizado, então eu acho que poderia compilar

Parece que você respondeu sua própria pergunta? Não sei por que você sente a necessidade de debater esse ponto quando sabe a resposta.

Como @StingyJack menciona, você não

Independentemente disso, temos uma solução alternativa documentada; Não tenho certeza de por que é necessário continuar qualquer discussão sobre isso.

porque agora você só precisa lidar com a referência do pacote, e não com as entradas duplicadas no arquivo csproj. Eu concordo em mantê-lo organizado.

E este novo formato de pacote não faz nada para resolver esses problemas (novamente o que @StingyJack está apontando aqui). Para um número trivial de PackageReferences / ProjectReferences, isso é gerenciável, mas quando você obtém mais de 50 deles, fica fora de controle sem qualquer tipo de classificação forçado.

@owenneil

Não tem inclusões explícitas apenas mova o problema?

Sim; mas ele o move de volta para o Desenvolvedor (no início do processo) e, melhor ainda, dá ao seu check-in fechado uma chance de interrogar os Arquivos CSPROJ ao adicionar; temos um gancho de confirmação que faz exatamente isso (se o arquivo CS for adicionado ou removido, certifique-se de que as alterações apropriadas foram feitas no arquivo CSPROJ).

@petertiedemann - tenha em mente que não apenas arquivos faltando, mas também arquivos extras.

Mas em uma configuração "normal" isso realmente não seria um problema, seria? Em todos os nossos ~ 200 repositórios (tudo, desde serviços da web, mecanismos de restrição a analisadores e compiladores de linguagem de domínio específico), não temos arquivos de origem na pasta do projeto que não queremos incluir (em qualquer um que usa o novo e o formato de projeto antigo). E mesmo se você tiver alguns projetos exóticos com esse problema, basta desabilitar as inclusões implícitas ou excluí-las explicitamente.

Parece que você respondeu sua própria pergunta? Não sei por que você sente a necessidade de debater esse ponto quando sabe a resposta.
...
Independentemente disso, temos uma solução alternativa documentada; Não tenho certeza de por que é necessário continuar qualquer discussão sobre isso.

Acho que porque a opinião expressa por você e @StingyJack parecia ser que as

E este novo formato de pacote não faz nada para resolver esses problemas (novamente o que @StingyJack está apontando aqui). Para um número trivial de PackageReferences / ProjectReferences, isso é gerenciável, mas quando você obtém mais de 50 deles, fica fora de controle sem qualquer tipo de classificação forçado.

Bem, o PackageReference certamente ajuda muito. Antes tínhamos pessoas desistindo de rebasear branches por causa de conflitos nas referências dll, agora raramente precisamos gastar tempo com isso.

Mas seus projetos têm cerca de 50 referências? Devo dizer que isso é um pouco, mas ainda estou surpreso que eles mudassem com freqüência suficiente para causar problemas significativos. Também consideramos expandir nossa ferramenta para lidar com PackageReferences, mas levaria muito mais tempo para implementá-la do que gastamos para lidar com ela manualmente.

@ jnm2

Existem padrões não documentados? O link que dei anteriormente parecia muito completo na área que li.

Depende do contexto; Eu li isso para indicar que o arquivo do projeto ainda é uma caixa preta em alguns aspectos. Embora a Microsoft tenha feito ENORMES avanços na documentação do comportamento e da intenção do Formato do Projeto nos últimos anos com o Microsoft Docs (e nós os agradecemos por isso!).

O primeiro que me vem à mente é o comportamento das Referências no sistema mais recente; existem alguns bugs muito sutis em torno da lógica de restauração. Veja este problema do NuGet https://github.com/NuGet/Home/issues/8272 muitos deles não são notados até que sejam tentados em escala e somente após uma avaliação cuidadosa.

Tenho certeza de que poderíamos continuar a escolher alguns comportamentos; mas é provavelmente irrelevante para a discussão em questão.

@petertiedemann

Acho que porque a opinião expressa por você e @StingyJack parecia ser que incluir implícito como padrão era um design ruim,

Acho que nunca usei as palavras "design ruim". Eu notei que:

Qualquer coisa que possa misturar a saída (adicionando "indeterminismo") é considerado um defeito do mundo DevOps.

O que, novamente, pode ser contornado simplesmente usando a solução alternativa postada: <EnableDefaultCompileItems>false</EnableDefaultCompileItems>

mas os casos levantados eram bastante exóticos, o que significa que as inclusões implícitas de fato parecem ser uma excelente escolha de design.

Quanto ao seu ponto de exótico ou não: o exótico de um homem é comum a outro. É o mundo em que vivemos, e as ferramentas foram / são escritas de forma que você seja livre para adaptá-las às suas necessidades. Acho que a frustração de StingyJack (junto com a minha) é que esses cenários são descartados como casos secundários (como você faz abaixo).

O cenário de teste de unidade que foi descrito basicamente vai contra a prática comum de como estruturar projetos, e não é um que eu já tenha visto antes.

O cenário de CI / CD de reflexão em tempo de execução é simplesmente um design assustador por si só, e parece quase impensável que nenhum teste existisse para falhar nesse caso (você definiu um tipo que nunca é usado em nenhum teste ou outro projeto?).

Ei, nem eu; mas estamos aqui hoje, não estamos? (Veja acima) Acho que sua incapacidade de aceitar que o sistema está sendo usado de forma perversa está causando muita frustração e peço desculpas. Não estou aqui para defender que isso seja de forma alguma bom ou aceitável, nem para questionar o estilo de vida. Estou simplesmente tentando incluir os casos de uso atuais que estão afetando os consumidores do produto.

Mas seus projetos têm cerca de 50 referências? Devo dizer que isso é um pouco, mas ainda estou surpreso que eles mudassem com freqüência suficiente para causar problemas significativos.

Ai sim! Facilmente. O problema é tão grave que escrevi uma ferramenta para ajudar a visualizá-lo! (Shameless Plug: https://github.com/aolszowka/MsBuildProjectReferenceDependencyGraph) na verdade, há um Processo de CI gerando automaticamente esses gráficos sobre cada commit, apenas para que possamos manter os desenvolvedores informados sobre a próxima mudança de baixo nível que irá queimar você em sua próxima atualização de svn! Esses gráficos são confirmados em seu próprio repositório para que as pessoas possam continuar atualizando para obter os mais recentes.

Esta é uma versão anônima de um arquivo de solução comumente usado pela maioria dos desenvolvedores. Jogue-o em seu programa favorito que suporta renderização dotGraphs (GraphViz por exemplo, e seu tão complexo WebGraphViz não funcionará) https://gist.github.com/aolszowka/a93ea5545d54344c61f66830fae90c4e leva cerca de 15-20 minutos para renderizar em meu trabalho pessoal estação. Ah, a propósito, isso é apenas ProjectReferences, a ferramenta não faz nenhuma tentativa de representar graficamente PackageReferences (ainda, eu aceito solicitações de pull!).

Tem sido uma verdadeira alegria ver a equipe Roslyn experimentar grandes soluções no Visual Studio (Roslyn.sln seria considerado pequeno internamente). No lado positivo, eles fizeram ENORMES passos para consertá-lo (porque os queima dia a dia), então pelo menos agora é possível carregá-los no VS 2017+. Ainda estou esperançoso de que eles cheguem ao fim da estrada em breve e percebam que precisamos fazer o Visual Studio de 64 bits para que não travemos de 3 a 5 vezes ao dia devido a erros de OOM.

mas levaria muito mais tempo para implementá-lo do que gastamos para lidar com ele manualmente.

Ah, como eu invejo você, mas lembre-se muito como cachorrinhos e gatinhos: Eles começam pequenos, mas crescem! Ao mesmo tempo, esses ramos eram sustentáveis ​​(provavelmente por que a atitude era "bem, o que é mais um?").

Pelo menos uma vez por semana internamente. Temos cerca de 70 desenvolvedores com média de 200 commits por semana, o tamanho médio dos commits é de 3 arquivos CSPROJ +/- 20 arquivos CS, a maioria são alterações em arquivos existentes com algumas adições espalhadas. FWIW estamos usando o Subversion, mas duvido que mude o VCS realmente ajudaria (já usamos Ankh, que fornece o overly). Até mesmo seus melhores desenvolvedores absolutos (seus desenvolvedores 10x) ocasionalmente cometerão um erro. É inevitável nesta escala e taxa de mudança.

@aolszowka
FWIW, minha equipe teve esse problema anos atrás, quando estávamos no SVN. Depois da migração para o Git, isso nunca mais aconteceu. Especialmente desde que começamos a bloquear check-ins no CI Passing.

@AlgorithmsAreCool

Especialmente desde que começamos a bloquear check-ins no CI Passing.

Com certeza; Acho que há alguma confusão aqui; realizamos esses check-ins hoje por meio de um gancho de confirmação do Subversion (que mantemos métricas e é por isso que posso dizer quantas vezes isso acontece), no entanto, o gancho de confirmação do Subversion precisa utilizar o CSPROJ para determinar o que é "correto", veja isto Comente:

Sim; mas ele o move de volta para o Desenvolvedor (no início do processo) e, melhor ainda, dá ao seu check-in fechado uma chance de interrogar os Arquivos CSPROJ ao adicionar; temos um gancho de confirmação que faz exatamente isso (se o arquivo CS for adicionado ou removido, certifique-se de que as alterações apropriadas foram feitas no arquivo CSPROJ).

Acho que porque a opinião expressa por você e @StingyJack parecia ser que as

Se eu não disse isso, estou falando sério, e não digo isso apenas para ser combativo ou petulante. Não há nada de exótico em ter um manifesto do que se espera que seja incluído no resultado final. A falta desse manifesto abre a porta para coisas inesperadas ("exóticas?") Serem incluídas no resultado final. Todas as outras profissões que criam algo têm uma lista explícita como esta. Colocando em outras palavras...

Você faria uma refeição sabendo que o chef não estava no controle dos ingredientes e da preparação dessa refeição?

Você permitiria uma reforma em sua casa quando soubesse que o empreiteiro geral não estava verificando a bitola da fiação elétrica usada ou se era de cobre ou alumínio antes de instalá-la?

Você tomaria um medicamento se soubesse que o produtor não tem controle total sobre a fabricação e embalagem desse medicamento?

Essas outras indústrias de "criação" podem ser regulamentadas e, portanto, obrigadas a usar uma lista explícita, mas as que não o usam a usarão porque é necessária para o planejamento e porque é uma maneira fácil de ter uma expectativa razoável de qualidade de produção semelhante. entre diferentes esforços. A segunda parte é a chave para nós; não podemos melhorar gradativamente algo se esse algo puder mudar de qualidade sem que sequer saibamos. Recentemente, descobri que algo assim estava acontecendo em um projeto Python em que trabalho. Algumas compilações seriam apenas _estranhas_, outras inutilizáveis. Descobri que logo no início, alguém adicionou vários pacotes ao arquivo setup.py e perdeu a vírgula entre um intervalo de versão superior e inferior. Foi uma coisa fácil para pelo menos 5 desenvolvedores qualificados perderem por quase um ano. Pip (o nuget.exe do python) leu a coisa toda como a versão inferior com alguma tag de pré-lançamento e começou sempre incluindo a versão mais recente, mesmo que fosse um pacote alfa.

Inclusões de código implícito, dependências de versão flutuante / curinga e referências transitivas incluídas automaticamente são uma conveniência, mas essa conveniência traz riscos para o sucesso de seus projetos que são muito reais. Com o último colocando o projeto à mercê de qualquer autor de pacote no cronograma de lançamento e qualidade de lançamento da cadeia de dependências (ou cronograma de não-lançamento - veja "botão esquerdo"). Presumir que esse risco deve ser uma opção e não o padrão. Não está preparando os programadores para o "poço do sucesso" de forma alguma.

Além disso, geralmente não estamos envolvidos na criação de software que tenha consequências imediatas de vida ou morte, mas todos estamos envolvidos na criação de software que tenha consequências de qualidade de vida para os usuários, para nós mesmos e para nossos colegas programadores. A comunidade .net tentou esse experimento de arquivo implícito na era .net v1 -2 com projetos de site da Web e, embora fosse ótimo quando você tinha o único caso de uso exótico em que precisava atualizar arquivos compiláveis ​​na hora, era péssimo ter para gerenciar tudo no projeto com base na presença ou ausência de arquivos (ou arquivos fantasmas - .dll.refresh ) ou extensões de arquivo específicas ( .excluded ). Mas o que foi realmente ruim foi quando algum tipo de poluição (como um arquivo indesejado ou a versão errada de um arquivo) apareceu e você teve que solucionar o problema. Qualquer pessoa que queira experimentar ainda pode fazê-lo, mas a maioria de nós usa projetos de aplicativos da Web - onde podemos controlar as entradas e saídas para obter um resultado previsível - em vez disso.

@StingyJack :

Não há nada de exótico em ter um manifesto do que se espera que seja incluído no resultado final. A falta desse manifesto abre a porta para coisas inesperadas ("exóticas?") Serem incluídas no resultado final. Todas as outras profissões que criam algo têm uma lista explícita como esta.

Por que o Git não é um "manifesto" suficiente para você? Se você estiver adicionando cargas de arquivos ao Git que não deveriam estar lá ou como parte do produto final, talvez você deva revisar seu processo de desenvolvimento?

@asbjornu - Acho que você quer dizer "sistema de controle de versão" e não especificamente git, correto? Em primeiro lugar, não se trata de controle de versão, e o AFAIK msbuild ainda requer que os arquivos estejam presentes em um sistema de arquivos, e não no VCS de nossa escolha. O comentário resumido que fiz acima em relação aos arquivos de projeto com todas essas inclusões e padrões implícitos é sobre o arquivo de projeto. Nunca foi um monte de arquivos que causou problemas com projetos de sites, foi sempre aquele arquivo que resultou em várias horas de solução de problemas.

Estou curioso para saber como você consideraria essas três perguntas que fiz sobre outras profissões, porque a minha resposta será Não, Não e Não. Se você também responderia "Não" a essas três, então considere o ponto de vista de um negócio da nossa profissão. Eles confiariam que um programador faria algo importante para seus negócios que não controlasse o que entra no programa?

Se você quiser usar um atalho com inclusões implícitas e puder gerenciar o risco associado, não tenho queixas. Mas tornar tudo isso implícito inclui o comportamento padrão para que eu tenha que trabalhar agora para mitigar um risco que eu não tinha a ver com o formato anterior é algo do qual vou reclamar.

@StingyJack :

Acho que você quer dizer "sistema de controle de versão" e não especificamente git, correto?

Não, quero dizer Git, já que a maioria dos outros sistemas de controle de versão não tem um histórico criptograficamente verificável, commits assinados e tags assinadas. Com isso implementado, você tem uma fonte muito forte de verdade sobre o que deve e não deve ser considerado parte do aplicativo resultante.

Se você atualmente permite que os desenvolvedores adicionem qualquer arquivo estranho ao seu VCS sem qualquer revisão de código, nenhuma verificação, nenhuma aprovação ou qualquer outro processo editorial em vigor, eu digo que o seu processo de desenvolvimento é o culpado aqui, não o sistema do projeto. A maioria das plataformas de desenvolvimento segue o mesmo caminho aqui de inclusão implícita; Node.js, Ruby, Python, PHP, Go, Rust, Docker, etc.

Eles confiariam que um programador faria algo importante para seus negócios que não controlasse o que entra no programa?

Por que você afirma que o programador não tem controle sobre seu VCS (de preferência Git)?

Não, quero dizer Git, já que a maioria dos outros sistemas de controle de versão não tem um histórico criptograficamente verificável, commits assinados e tags assinadas. Com isso implementado, você tem uma fonte muito forte de verdade sobre o que deve e não deve ser considerado parte do aplicativo resultante.

Um "histórico criptograficamente verificável, confirmações assinadas e tags assinadas" não descreve a intenção do desenvolvedor. Você pode assinar criptograficamente o que quiser; essa propriedade não significa que seu conteúdo deva ser confiável (e é o argumento de @StingyJack ).

Por que você afirma que o programador não tem controle sobre seu VCS (de preferência Git)?

Isso pressupõe que os desenvolvedores do sistema são competentes ou, pelo menos, não são maliciosos. Pergunte a event-stream como isso funcionou para eles (e todos os upstream que queimaram "Não sei o que dizer" para mim foram a citação de 2018).

Oi pessoal,

Achamos que, para a maioria das pessoas, incluir automaticamente todos os arquivos com a extensão correta faz sentido. Para aqueles que não desejam esse comportamento, você pode desativá-lo definindo a propriedade EnableDefaultItems como false.

Isso está de acordo com a filosofia que tínhamos ao projetar os arquivos de projeto atualizados, que era ter padrões razoáveis ​​que poderiam ser substituídos quando necessário.

Tem havido uma tonelada de discussão sobre este assunto e parece que tem sido um ponto-chave para qualquer comentário sobre o formato do arquivo do projeto. Isso torna menos provável que recebamos e respondamos aos comentários. Se você tem coisas concretas causando problemas, recomendo criar novas questões para elas.

Obrigado!
Daniel

@aolszowka :

Um "histórico criptograficamente verificável, confirmações assinadas e tags assinadas" não descreve a intenção do desenvolvedor.

O log de confirmação deve refletir a intenção do desenvolvedor. Cada confirmação pode ser assinada para identificar o desenvolvedor do referido código. Uma revisão de código assinada por outra pessoa pode verificar duas vezes a intenção. Uma confirmação de mesclagem assinada e marcada das confirmações revisadas pode verificar três vezes a intenção. Quantas verificações você precisa?

Você pode assinar criptograficamente o que quiser; essa propriedade não significa que seu conteúdo deva ser confiável (e é o argumento de @StingyJack ).

Ninguém em sua equipe é confiável, nem mesmo uma cadeia de comando capaz de aprovar revisões de código ou mesclagem de commits marcados?

Por que você afirma que o programador não tem controle sobre seu VCS (de preferência Git)?

Isso pressupõe que os desenvolvedores do sistema são competentes ou, pelo menos, não são maliciosos.

Se todos os seus desenvolvedores forem incompetentes e / ou maliciosos, ter inclusões explícitas nos arquivos de projetos não fará diferença. Se ter três pessoas diferentes em níveis diferentes na cadeia de comando, assinar criptograficamente e aprovar uma série de commits não é suficiente para você (é codificar sob a submissão de um processo de revisão PCI-DSS ), então nada será.

Pergunte a event-stream como isso funcionou para eles (e todos os upstream que queimaram "Não sei o que dizer" para mim foram a citação de 2018).

Irrelevante e incomparável para o processo que estou descrevendo. Se um controle hostil de um repositório Git for possível em seu processo e VCS, seu processo e VCS serão quebrados, não seu sistema de projeto.

Esta página foi útil?

0 / 5 - 0 avaliações