En el standup, Damian menciona que tal vez las cosas relacionadas con Nuget se trasladen a algo que será un reemplazo para el package.config actual. Obviamente, estas decisiones son un camino justo en el futuro, dudo que obtenga respuestas concretas en este momento.

Y no estoy de acuerdo en que "JSON sea sin duda más simple para representar esas dependencias". Hay pros y contras. Vea esto https://gist.github.com/darrelmiller/07fed784d2c20de9f5d3719977167181

Estoy de acuerdo con el cambio _si_ se mudaran a nuget.json. esa es la única parte de project.Json que pensé que debía ser dev editable de todos modos.

@darrelmiller Yaml es probablemente una alternativa aún mejor en términos de verbosidad. Y hiciste trampa con la cadena separada por comas en lugar de matrices;).

@sandorfr Lo es. Sin embargo, sospecho que una de las razones para volver a un sistema de proyectos basado en XML se debe a las importantes herramientas existentes en torno a los sistemas de proyectos basados ​​en XML en el ecosistema .net. Mis comentarios no son para tratar de identificar el mejor formato, solo para señalar que XML no es intrínsecamente malo.

Sí y esa es la peor noticia de esta semana. Es como retroceder en el tiempo ... :( De hecho, Xml no es malo, sin embargo, msbuild ... Y un proyecto base xml de msbuild no será tan hábil como describiste.

Sin embargo, sospecho que una de las razones para volver a un sistema de proyectos basado en XML se debe a las importantes herramientas existentes en torno a los sistemas de proyectos basados ​​en XML en el ecosistema .net.

Simplemente no entiendo por qué todas las cosas tienen el sufijo " core " para indicar que es algo completamente nuevo si la intención también es llevar el equipaje adelante como msbuild.

El proceso ha sido demasiado doloroso durante más de dos años, pero mucha gente estaba bien porque todas las nuevas adiciones y mejoras estaban alineando el ecosistema con otros ecosistemas y todos ellos fueron cambios por buenas razones. Sin embargo, de repente, los desarrolladores empresariales de materia oscura empezaron a dar su opinión a puerta cerrada y estamos viendo que hay mucho equipaje que llevar adelante.

No hay muchos ecosistemas que tengan una configuración basada en XML. De hecho, todos los nuevos ecosistemas diseñados están adoptando otros formatos (YAML, JSON, etc.). Mira la reacción de todas las personas en las redes sociales, no veo a muchas personas a las que les guste este cambio. Sin embargo, la retroalimentación que se ha dado en forma privada parece más importante para el equipo. Eso no es malo, entiendo las razones, pero solo muestra la forma en que se procesan las decisiones en este ecosistema.

+1 en las peores noticias de la semana. ¿Dónde estaba la discusión sobre esto? No encuentro nada, solo una decisión unilateral.

No veo ningún apoyo de la comunidad para esta decisión, y mucho en contra (85% a 15% en el último recuento). ¿Cómo fue la discusión, quién tomó la decisión, en base a qué información?

¿Es así como estamos haciendo las cosas en .NET Core? ¿Comprometer la calidad a puerta cerrada porque queremos respaldar una lista no divulgada de tecnología heredada?

Por supuesto, hagamos una extensión VS que cree un .csproj a partir de un project.json que las personas que usan esas viejas tecnologías puedan usar.

Pero no nos devuelva a la pesadilla de los archivos de proyecto basados ​​en XML. Eran una mala idea cuando se introdujeron, y hemos estado pagando el impuesto de las malas fusiones y la dificultad de lectura durante más de una década. Es suficiente.

Creo que estás siendo demasiado pesimista, y supongo que eso se debe principalmente a que a todos nos sorprendió esto. Permítales compartir más información sobre sus planes y luego veremos. @DamianEdwards dijo claramente que quieren mantener las partes buenas del modelo project.json.

En mi opinión eso sería:

• no tener que especificar cada archivo cs
• poder modificar el archivo sin tener que descargar el proyecto
• poder modificar las dependencias de nuget directamente en el archivo (con IntelliSense)
• poder reemplazar los paquetes nuget con la fuente local a través de global.json

En términos de compilación, creo que debería ser posible compilarlo sin tener instalado Visual Studio. Para mí, no importa si el comando real es "dotnet build" o "msbuild". Lo importante es que debería haber una forma de compilar la solución completa, que, por cierto, aún no existe en "dotnet cli" (al menos no que yo sepa).

Si esto se puede lograr, estoy de acuerdo con cualquier sintaxis que usen. XML no es genial, pero JSON claramente también tiene sus desventajas.

Editar: creo que esto no cambia ninguna de las ideas fundamentales (y excelentes) de .NET Core, etc.

En mi humilde opinión, el principal problema es que este tipo de cambios drásticos justo antes de RTM no es bueno. Si esto sucede en tiempos beta, es posible que los desarrolladores / equipos no se sorprendan tanto. Piense en las inversiones que la gente está haciendo desde los últimos 2 años . Piense en los productos / bibliotecas / marco actuales según el sistema project.json . Asp.Net está en RC no en vista previa / alfa / beta, este tipo de cambios rompen la confianza de los desarrolladores / equipos :(.

En mi humilde opinión, el principal problema es que este tipo de cambios drásticos justo antes de RTM no es bueno.

Yo también lo pensé al principio, pero hasta donde tengo entendido, esto no dará como resultado ningún cambio en el código de su aplicación. Solo afectará sus archivos project.json / xproj / csproj y dijeron que el cambio podría ser automático, por lo que será similar a los buenos pasos de migración de proyectos antiguos que ya sucedieron muchas veces cuando actualizó Visual Studio.

Por cierto, siempre pensé que tener un project.json y un archivo xproj (que contiene el espacio de nombres predeterminado para las plantillas de Visual Studio y algunas rutas de salida, por lo que a veces también tienes que editarlo) era extraño.

Por cierto, siempre pensé que tener un project.json y un archivo xproj (que contiene el espacio de nombres predeterminado para las plantillas de Visual Studio y algunas rutas de salida, por lo que a veces también tienes que editarlo) era extraño.

Tal vez sea extraño, pero responden a cosas diferentes. Project.json es el único archivo necesario para construir un proyecto principal .net y xproj está relacionado con herramientas patentadas, también conocidas como visual studio. Es muy similar con package.json y .idea si usa webstorm para trabajar en sus proyectos de nodo. Solo separación de preocupaciones. Visual Studio podría ocultar project.json en Propiedades si lo desea y ofrecer una experiencia de interfaz gráfica de usuario curada combinada si lo desea sin mezclar todo.

He estado usando estas cosas en una mac en VS Code durante tanto tiempo que me olvidé de xproj. ¡OTOH, realmente extrañé la depuración y bastante más de Visual Studio!

Creo que estás siendo demasiado pesimista, y supongo que eso se debe principalmente a que a todos nos sorprendió esto.

No, lo siento, no creo que sea demasiado pesimista. XML es un formato incorrecto para cualquier situación en la que vaya a realizar combinaciones de código, es decir, todos los proyectos de software. XML no fue diseñado para cosas como archivos de configuración y archivos de proyecto, y nunca debería haber sido usado para ellos, .NET simplemente tuvo la mala suerte de ser reconstruido cuando todos pensaban que XML podía resolverlo todo.

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

Ahora, .NET Core se está construyendo cuando todos piensan que JSON resolverá todo. No creo que JSON sea una solución a largo plazo más que XML, pero sé que es más fácil fusionar conflictos JSON que XML.

Me ha parecido un soplo de aire fresco no lidiar con la basura XML para los archivos de proyecto, me resultó más fácil leer los archivos JSON, me resultó más fácil trabajar con los archivos JSON fuera de Visual Studio, y no quiero volver a XML / MSBuild.

Sí, estos son mis sentimientos personales, y sí, son subjetivos, pero según los comentarios en Twitter y en otros lugares, no creo que estén aislados. Para ser honesto, esta decisión me hace dudar por completo de toda la dirección de .NET Core y, más especialmente, de la forma en que se toman decisiones importantes como esta.

@DamianEdwards dijo claramente que quieren mantener las partes buenas del modelo project.json.

Desde mi perspectiva, las mejores partes del modelo project.json son que no es csproj, ni MSBuild ni XML. ¿Se conservarán esas partes "buenas"? Aparentemente no. Después de que nos engañaron haciéndonos creer que finalmente se estaban tomando el césped, resulta que todo fue una mala dirección. Nos hablaron sobre el nuevo sistema de compilación, sobre Gulp y project.json y cómo las cosas serían diferentes ahora, y luego resultó que todo era una farsa y es el viejo y horrible MSBuild de nuevo.

Creo que los formatos JSON y XML son prácticamente los mismos en términos de fusión: ambos tienen etiquetas de cierre (aunque es solo un corchete en JSON), lo que significa que tiene problemas con escenarios vacíos / uno / muchos. Simplemente cambie una matriz JSON vacía a una con elementos. Yo diría que JSON incluso tiene la desventaja adicional de la coma final que cambia dos líneas si agrega un elemento a una lista.

Tendrías que cambiarte a YAML, etc. si quieres evitarlo.

En mi opinión, el problema con csproj no es con XML sino con la forma en que Visual Studio lo trató y que contenía todos los archivos cs. Si esto se soluciona y si las herramientas no cambian aleatoriamente las cosas en el archivo, la fusión ya no debería ser un problema.

Sin embargo, en términos de legibilidad, también prefiero JSON. Pude escribir un project.json desde cero; supongo que ya no podré hacer eso con el csproj (csproj requiere un ProjectGuid aleatorio, etc.). Así que definitivamente necesitaremos soporte de herramientas / línea de comandos para esto.

Mi principal preocupación acerca de todo esto del que no he escuchado mucho es que project.json es mucho más declarativo cuando se trata de referencias que los archivos de proyecto .csproj . La belleza de las dependencias en el archivo project.json y la razón por la que estaba deseando migrar nuestro código base es que simplemente dices "Necesito esta dependencia" y no importa si es un proyecto local o un Paquete NuGet. En nuestro caso, esto nos daría mucha flexibilidad y nuevas opciones interesantes. En contraste, actualmente una referencia en un archivo .csproj es una ruta rígida y relativa a un archivo .dll en el disco. En este momento, agregar una entrada a su packages.config en un proyecto tradicional realmente no hace nada, también necesita agregar una referencia a un .dll específico de ese paquete al archivo .csproj . Eso lo hacen las herramientas NuGet dentro de Visual Studio, pero no quiero usar esas herramientas cuando agregar una línea de texto a un archivo project.json es mucho más simple.

Reconozco que el equipo quiere mantener toda la funcionalidad proporcionada por el archivo project.json y expandir las características del formato .csproj , pero también hablaron sobre mantener project.json como un archivo para especificar sus paquetes NuGet. No veo qué agregaría eso en comparación con la situación actual con packages.config donde simplemente agregar una entrada no es suficiente porque aún necesita agregar una referencia a .dll en el .csproj también. Si el archivo .csproj se convertirá en el futuro, preferiría que el equipo de Core vaya hasta el final y suelte project.json o nuget.json o, como sea, termine llamándose _entirely_ y agregue una forma más declarativa de agregar referencias al formato .csproj . Puedo vivir bien con tener que editar un archivo XML en lugar de un archivo JSON (aunque ciertamente prefiero JSON) pero sería una verdadera lástima perder la naturaleza declarativa de project.json y no necesito dos diferentes lugares donde necesito especificar mis dependencias.

Envíe sus comentarios en https://www.surveymonkey.com/r/H6Q88PP

Para que quede claro, al leer las notas de Standup, menciona que una opción es tener una instalación nuget, una especie de opción de guardar (consulte https://blogs.msdn.microsoft.com/webdev/2016/05/11/ notas-de-la-comunidad-asp-net-standup-10-2016 /). Si bien creo que es una buena idea, reemplazar el 'editar archivo .json con intellisense' con eso creo que es una mala idea. Creo que permanecer en el editor es una buena idea para algunos de nosotros que no queremos cambiar a un shell para hacer todo. Mi preferencia, personalmente, es tener ambas experiencias. línea de comandos + interfaz de usuario para agregar dependencias no es lo suficientemente bueno.

Soy un codificador, no quiero dejar el editor.

Creo que esta es una decisión horrible. Ustedes dijeron que querían que .NET Core fuera realmente simple, pero luego hicieron este cambio. No me importa cuánto lápiz labial se ponga en MSBuild, seguirá siendo MSBuild y los forasteros lo verán y se apagarán de inmediato. Nunca será un formato simple editable a mano. Tal vez hubo algunos problemas técnicos difíciles, pero parece que estaban relacionados con tratar de convertir el sistema de proyectos en algo más que un simple sistema de proyectos. Si la gente quiere hacer cosas más complejas en sus compilaciones, entonces pueden escribir algunos scripts o usar msbuild para hacerlo. project.json es una cosa maravillosamente simple y estoy realmente desanimado ahora.

¿Mi cita favorita sobre archivos MSBUILD?

Recientemente tuve que pasar mucho tiempo con archivos csproj. Se parecen y se comportan bastante como Ant / Maven. Este no es un punto a su favor.
Ant / Maven fue amado y luego odiado por muchos desarrolladores de Java. XML es una sintaxis extremadamente detallada con la que hay que lidiar.
Pero el verdadero asesino es el encierro. Sí, puede usar msbuild para hacer cosas con ellos, pero la sintaxis está realmente diseñada no para que un desarrollador los lea / edite, sino para que un IDE serialice el estado. El hecho de que haya un corredor de línea de comandos no significa que el formato sea amigable para los desarrolladores. Mientras permanezca en VS, realmente no lo notará. Tan pronto como te vayas, ya no será cómodo. Los archivos csproj son una cosa que desearía que .Net hubiera tomado una ruta diferente a la de Java.

Fuente

Creo que es importante hacer una distinción entre MSBuild y la forma en que Visual Studio usa actualmente MSBuild. He estado editando manualmente archivos de MSBuild durante años y los uso para todos mis proyectos. Por ejemplo, https://github.com/tavis-software/Tavis.home/blob/master/build/Build.proj

Los archivos csproj que crea Visual Studio son bastante desagradables, pero culpar a MSBuild de eso es como decir que C # es una mierda porque vio a un generador de código crear un código desagradable con él una vez.

@darrelmiller estoy de acuerdo.

Avancemos el tiempo 6 meses y veamos si es un momento de "te lo dije" o más de "esquivé una bala".

Después de la llamada de @shawnwildermuth en su blog, arrojaré mis propios 2 centavos:

No veo por qué esto es tan importante. Me complace volver a un csproj basado en XML porque:

• Editar JSON manualmente NO es más natural / fácil que XML. En realidad, es todo lo contrario en mi humilde opinión. Cada editor estúpido me da la finalización de la etiqueta XML, detectar un error de formato manualmente es más fácil y así sucesivamente. JSON no es más fácil si tengo que escribirlo manualmente. Decir eso me lleva al punto 2 ...
• ¿Por qué hay tanto alboroto sobre la edición de un archivo de proyecto con un editor en primer lugar? La edición de un archivo de proyecto NO es donde quiero pasar mi tiempo como desarrollador. Esto debería ser algo único al comienzo de un nuevo proyecto, pero después de eso no debería suceder muy a menudo en mi humilde opinión. Si tengo que editarlo con JSON, XML, YAML, TOML o lo que sea que alguien quiera en ese momento es completamente irrelevante para mí.
• Lo único que me gustaría evitar es acoplar estrechamente NuGet con ASP.NET . NuGet es genial, me encanta y quiero que mi ASP.NET funcione muy bien con él, pero NO es necesario para ejecutar ASP.NET. Sí, es posible que necesite extraer los binarios de una fuente de NuGet para obtener las características de MVC, etc., pero si lo hago a través de la fuente oficial de NuGet, o si extraigo las fuentes, lo compilo localmente y lo copio y lo pego en un La carpeta debe ser una flexibilidad que permanezca disponible para mí. No quiero que ASP.NET, el csproj o cualquier otra cosa estén estrechamente acoplados a esos sistemas de terceros "compatibles". Quiero que permitan una gran integración, ¡pero mantengan la puerta abierta para la personalización ! Por lo tanto, espero que los paquetes NuGet no se declaren en el archivo .csproj y que un nuget.json no se integre estrechamente en MSBuild.
  Estrecha integración detrás de una interfaz bien definida == EXCELENTE.
  Acoplamiento estrecho, asumiendo que este es el estándar para todos == MALO.
• Por último, quiero decir que project.json tiene muy poco que ver con .NET Core y ASP.NET Core. Core tiene mucho más que ofrecer que un archivo project.json. Project.json no era una característica nueva, era un intento de rediseñar algo que ya existía en un formato diferente. Eso no me importa demasiado, porque como desarrollador prefiero centrarme en las nuevas características y posibilidades que ofrece .NET Core para desarrollar una gran aplicación en la nube en lugar de la aburrida configuración que tengo que hacer de vez en cuando.

Creo que es un gran paso volver a MSBuild, porque como desarrollador me preocupo más por la compatibilidad y creo que esta es la clave. MSBuild funciona, y para ser justos, funciona muy bien en su mayor parte y en lugar de reemplazarlo con algo nuevo, lo que trae nuevos problemas y causa problemas de compatibilidad, prefiero que alguien mejore las cosas que ya funcionan y las mejore con el tiempo. Todos piensan que pueden reescribir cosas y mejorarlas, hasta que te das cuenta de que solo resolviste un pequeño espacio de problema que era importante para ti en ese momento y luego, cuando quieres expandirte, te encuentras reconstruyendo lo mismo que antes. intentaste reemplazar al principio. Mejor mejorar las cosas que ya funcionan.

Esta es también la razón por la que probablemente hubiera preferido mejorar Mono y cerrar las brechas en lugar de implementar un nuevo tiempo de ejecución multiplataforma, pero esa es una discusión diferente.

Resultados finales de la encuesta: 100 respuestas, para una población de desarrolladores de .NET de 9 millones que es ± 10% con un 95% de confianza.

¿Te gustó el cambio a project.json?
Sí, fue una de mis funciones más esperadas 19,19%
Sí 39,39%
No 13,13%
No, fue una mala dirección tomar el 16,16%

¿Está contento de volver a MSBuild?
Sí, ahora puedo pensar en adoptarlo 9.09%
Sí 16,16%
No 30,30%
No, esto me hace cuestionar la dirección que está tomando .NET Core 29.29%
No me importa 15.15%

¿Cree que se mejorará MSBuild
¿Mejorado? Ya es perfecto. 1,01%
Sí 63,64%
No 12,12%
Está fundamentalmente roto, ¿cómo se puede mejorar? 20,20%
No me importa 3.03%

¿Crees que esta decisión se tomó correctamente?
Sí, el equipo aceptó los comentarios y cambió de dirección cuando tenían que llegar al 20,41%.
Sí 6,12%
No 24,49%
No, el equipo tomó decisiones irresponsables, a puerta cerrada, sin involucrar a la comunidad 39,80%
No me importa 9.18%

¿Cómo afecta esta decisión a su percepción de .NET Core?
Lo mejora, finalmente están recuperando la cordura 13.00%
Mejora 11,00%
Lo empeora 42,00%
Lo empeora, me hace cuestionarlo todo 18,00%
No me importa 16%

100 personas hicieron la encuesta. Ni siquiera lo sabía hasta ahora. Miremos de nuevo cuando tengamos números representativos, porque 100 personas es una broma de mal gusto como mucho.

En realidad, como se indicó, 100 personas le dan un margen de error de ± 10% con un 95% de confianza. ¿Qué nivel de confianza necesitaría para ver que está viendo un reflejo fiel? ¿Debemos encuestar a los 9 millones de desarrolladores?

¿Los 800 votos en UserVoice para extender project.json al resto de VS no muestran también la tendencia?

Y si vamos a hacer una muestra verdaderamente representativa, tal vez Microsoft debería hacerlo. Dado que ni una sola vez han pedido su opinión sobre esta decisión, incluso después de repetidas quejas de numerosas direcciones.

Tendrán un alcance mucho mejor que yo haciendo una encuesta privada. Necesitaría actualizar mi plan de SurveyMonkey para acceder a más de 100 resultados, a un costo para mí, para poder ejecutar una encuesta que Microsoft debería haber hecho ellos mismos.

Bueno, si quieres tener números significativos, entonces debes apuntar a una representación justa de los 9 millones de desarrolladores. Si tengo 100 seguidores en Twitter, que me siguen porque compartimos el mismo interés y les pido a todos que respondan la encuesta, entonces tienes 100 personas con una vista muy unilateral que representa solo a un grupo particular de desarrolladores.

La justificación dada en el standup para resucitar MSBUILD fue hacer posible la integración entre las herramientas existentes y facilitar que los proyectos existentes hagan uso de .NET core. Sin embargo, después de migrar un proyecto bastante grande a .NET core, para ser honesto, el sistema de proyectos fue el MENOR de mis desafíos. Así que usar eso como única justificación no me parece una gran razón. También he trabajado durante años con el sistema csproj, incluida la edición manual de archivos. Eso siempre fue doloroso. El sistema basado en project.json es MUCHO más simple y mucho más accesible para todos (incluidos los novatos). Creo que este es el objetivo. Y, sin embargo, ahora estamos dando un paso atrás al resucitar MSBUILD. Mi opinión personal es que esto es un gran error. Puse mi voto para mantener project.json.

En realidad, casi no tengo seguidores en Twitter, son en gran parte seguidores de los desarrolladores de .NET Core en cuyas transmisiones de Twitter publiqué.

Y, de nuevo, ¿seguramente las personas adecuadas para realizar tal encuesta serían Microsoft? ¿Por qué me queda ser el único que pregunta a la gente qué es lo que quiere?

¿Por qué a la EM no le importa un carajo lo que piense la gente?

TBH No sabía que había una encuesta hasta hace 30 minutos y no sabía que estaba haciendo la encuesta en privado. Estoy de acuerdo ... si Microsoft tiene interés en la reacción de los desarrolladores a este cambio, entonces deberían realizar una encuesta de este tipo. Pero tal vez ya hicieron sus deberes y por eso están haciendo este cambio. No lo sé, pero no siempre vería las cosas de manera tan negativa, porque después de todos estos muchachos están construyendo estas cosas para nosotros, así que estoy seguro de que solo tienen lo mejor para nosotros.

Si hubieran hecho sus deberes, habrían sabido que el 60% de los desarrolladores estaban en contra de este movimiento y se habrían comunicado y comprometido en consecuencia. No lo hicieron, lo que significa que no tenían idea de la reacción, lo que significa que no participaron.

Soy un cliente de pago con licencias empresariales para VS. No vi nada. Trabajo en cuatro firmas de servicios de primera categoría, que también pagan a clientes empresariales. No vieron nada. Entonces, ¿quién exactamente qué se comprometen con? He estado haciendo esa pregunta desde anoche y no he recibido ninguna respuesta.

Veo las cosas negativamente porque este es un cambio masivo y de última hora en una parte fundamental de la historia de .NET Core, una parte que nos fue comunicada como fundamental para el futuro, y nosotros (quizás estúpidamente) los tomamos en su Word, y hemos construido una tubería de CD / CI basada en esta tecnología que ahora es absolutamente inútil. También lo veo negativamente porque en un día completo de pedir detalles sobre la toma de decisiones ha habido un silencio absoluto en la radio.

Parece, por lo que he oído, que han arrojado a los usuarios debajo del autobús para ayudar a los fabricantes de herramientas. Si es así, ¿pueden cobrar mis tarifas de licencia VS a los fabricantes de herramientas y no a mí?

@shederman Si bien estoy de acuerdo con los resultados de su encuesta, sus preguntas obviamente están inclinadas en la dirección preferida de permanecer en el formato json, y eso realmente no la convierte en una buena encuesta. Lo tomé por diversión y no tomaría en serio sus resultados (lo siento). Me pregunto por qué no podemos tener ambos: hacerlo opcional de una forma u otra, porque no soy fanático de msbuild o esas otras cosas. Amo a json, es mi amigo.

Estoy de acuerdo contigo en que no es una encuesta ideal. Lo creé en el espacio de 5 minutos. el punto es: ¿por qué lo estoy creando?

¿Por qué Microsoft no está interesado en saber lo que piensa la gente?

Solo esperaba unas 30 respuestas, y esperaba que fuera suficiente para convencerlos de reabrir la discusión, compartir su pensamiento abiertamente y participar adecuadamente con nosotros en lugar de pasar por alto las opiniones.

Ahora tiene 138 respuestas, pero todavía no hay señales de Microsoft incluso considerando que tal vez su decisión fue mala. Solo explicaciones muy vagas agitando la mano que no están respaldadas por los hechos.

Todo lo que quiero es un compromiso adecuado con esta decisión. No se toman decisiones importantes a puerta cerrada basadas en información secreta y comentarios. Esto debe hacerse de forma abierta y transparente, palabra que ha estado singularmente ausente en este proceso.

Oh chicos, vamos. Microsoft es dueño del marco y le permite hacer lo que quiera. Pero piense por un momento, la gente está trabajando en esto desde marzo-abril de 2014 y justo antes de 1 mes de lanzamiento, hacer este tipo de cambio dramático es ridículo. Rompe la confianza de los desarrolladores. Pierde el tiempo de la gente. No es necesario crear un marco de código abierto si no puede confiar en la comunidad. Ve y hazlo cerca de la fuente de inmediato para que nadie te moleste cuando hagas este tipo de cambios en las habitaciones oscuras.

Solicito que Microsoft apologista y comprensivo (MVP o miembros de la comunidad) sea realista en este momento.

@shederman

Si hubieran hecho sus deberes, habrían sabido que el 60% de los desarrolladores estaban en contra de este movimiento,

Me sorprendería que más del 20% de los desarrolladores del ecosistema .net conocieran la existencia de project.json. A veces olvidamos que vivimos en una especie de burbuja de desarrolladores, a la vanguardia de los nuevos desarrollos tecnológicos.

Creo que gran parte del atractivo de project.json es su simplicidad. Sin embargo, si ha estado siguiendo su desarrollo desde que se presentó por primera vez en el día de ASP Net Insiders hace 3 años, ha comenzado a acumular más complejidad a medida que intenta admitir más casos de uso. Con el fin de respaldar todo el ecosistema .net, me temo que se perdería gran parte de la amada simplicidad.

Esto no quiere decir que project.json no traiga algunas características nuevas increíbles, y creo que hacer que el formato del proyecto sea más accesible para los humanos es algo bueno. Sin embargo, creo que llevar esa bondad a MSBuild es más alcanzable y beneficiará a mucha más gente antes que intentar llevar project.json a todas partes.

Me sorprendería que más del 20% de los desarrolladores del ecosistema .net conocieran la existencia de project.json.

Apostaría a que menos del 20% de los desarrolladores en .net eco conocen MVC y Web Api. Más de 70 personas utilizan WebForms, WCF, WebService. Nuevamente le pido a Microsoft apologista y comprensivo que sea realista

@shederman Su informe de confianza de los resultados de su encuesta probablemente sea incorrecto para la población de desarrolladores de .NET en general, y puede que ni siquiera sea una buena muestra representativa de ... "esos son en gran parte seguidores de los desarrolladores de .NET Core en cuyas transmisiones de Twitter publiqué ". Su muestra no es

No se pueden extraer conclusiones estadísticas útiles sobre la base de su encuesta para la población en su conjunto. Sin embargo, me alegro de que hicieras la encuesta. Presenta muchos puntos excelentes. Creo que los resultados indican que muchas personas están molestas o preocupadas por el cambio. Sin embargo, no publique conclusiones estadísticas falsas ... haciendo pasar números que prácticamente no tienen sentido y haciendo comentarios tan escandalosos como "habrían sabido que el 60% de los desarrolladores estaban en contra de este movimiento".

Entonces, ¿de qué sirve cambiar algo si vamos a molestar al 70% o más de la base del mercado? Quedémonos exactamente donde estamos y sigamos haciendo una evolución incremental. Si no está roto, no lo arregles, ¿verdad?

Sé que project.json ha acumulado complejidad. Estoy 100% de acuerdo en ese punto. ¿Fue la solución volver a fusionarse con csproj? Le dije a la gente antes que estoy completamente detrás de Microsoft por hacer las cosas bien en lugar de enviarlo a toda prisa. El cambio a csproj parece apresurado.

¿Por qué hacer esto después de RC2? ¿De dónde viene esto? ¿La adquisición de Xamarin tuvo algo que ver en esto? ¿Fue la integración dotnet-cli ? ¿Fue un gran cliente? Quién sabe...

Podría explicar a las masas que RC1 -> RC2 era lo mejor. Unificado con dotnet cli. ¿Pero el cambio project.json? No tengo nada que decir para explicarlo. Solo que no lo sé. La gente está confundida y no tengo argumentos convincentes para ellos.

¿Por qué hacer esto después de RC2? ¿De dónde viene esto? ¿La adquisición de Xamarin tuvo algo que ver en esto? ¿Fue la integración dotnet-cli? ¿Fue un gran cliente? Quién sabe...

Este es el pensamiento fundamental. No conocemos la historia completa detrás del cambio a csproj. Ahora, en lugar de recostarse, relajarse y ver y comprender por qué sucede esto, todos están maldiciendo a Microsoft y asumiendo lo peor. Esto no tiene ningún sentido. Estos muchachos están construyendo estas cosas para nosotros y solo para nosotros. Definitivamente no hacen tales cambios debido a un gran cliente, porque un gran cliente no vale nada si se arriesga a perder a toda su comunidad. El ecosistema de Microsoft .NET es HUUUUUUGE y hacer que .NET Core se adapte perfectamente a él es obviamente una tarea compleja, por lo que sugeriría que todos se relajen un poco y asuman que estos tipos tienen algunas personas inteligentes detrás, tomando las decisiones correctas para que podemos beneficiarnos al máximo de ella: a largo plazo. Estoy fuera de aquí, porque toda esta especulación prematura negativa me está aburriendo.

@darrelmiller Lo siento, cuando digo 60%, me refiero al 60% de los que respondieron la encuesta.

@GuardRex Tienes toda la razón. La única organización que puede darnos resultados adecuados es la EM, y no parece importarles.

Mi encuesta estaba destinada simplemente a medir un nivel vago de apoyo, no a proporcionar una muestra estadísticamente significativa. Creo que he demostrado que hay suficiente infelicidad para abrir esta decisión, pero parece que Microsoft no está de acuerdo, bueno, si su silencio de radio es una indicación.

Aquí está la pregunta: ¿qué se requeriría exactamente para que MS admitiera que tal vez cometió un error? ¿Qué se necesitaría para que reabrieran la discusión? Porque en este momento parece que la respuesta es "no nos importa su punto de vista, nuestra decisión es válida y no vamos a compartir las razones".

Sugeriría que todos se relajen un poco y asuman que estos muchachos tienen a personas inteligentes detrás, tomando las decisiones correctas para que podamos beneficiarnos al máximo de ellas, a largo plazo.

Eso es lo que dije que sea de código cerrado porque las personas inteligentes detrás de él y siempre tienen la razón y la comunidad de código abierto es tonta.

@shederman "no para proporcionar una muestra estadísticamente significativa" ... está bien, pero me gustaría que dejara que la encuesta se basara en sus propios méritos y eliminara esta línea ...

Resultados finales de la encuesta: 100 respuestas, para una población de desarrolladores de .NET de 9 millones que es ± 10% con un 95% de confianza.

Esa es la parte que se pone realmente peligrosa. Puede ser exacto que el 60% de los desarrolladores de .NET odien o no les guste este cambio; sin embargo, no puede mostrarlo con esa muestra. Digamos que sí, a muchos desarrolladores les preocupa mucho el cambio y la forma en que se manejó. Eso está claro, y la encuesta realmente destaca ese punto.

@abcplex : El código abierto no significa que tengas que saltar cada vez que 16 personas abren un problema en GitHub y gritan saltar.

@MaximRouiller The Standup Notes hacen un buen trabajo al explicar la motivación de los cambios. Y la realidad, tal como la leo, es que xproj está siendo reemplazado por csproj y project.json probablemente cambiará de nombre a nuget.json y _algunas_ cosas se moverán fuera de project.json.

Y a partir de los comentarios hechos en el standup, esta fue una decisión bastante reciente, se le dijo a la comunidad casi de inmediato, project.json no irá a ninguna parte hasta después de RTM, por lo que los cambios podrían ocurrir nuevamente.

Para mí, este parece el proceso más inclusivo y transparente que podría haber ocurrido.

@darrelmiller Eso, tendré que estar de acuerdo contigo. Bastante transparente.

Si querían retroalimentación, creo que la obtuvieron. En cualquier caso, no hay forma de combatirlo. La gente habló. Microsoft escuchó. Veamos si es algo sobre lo que puedan hacer algo o si tienen las manos atadas.

Solo el tiempo nos lo dirá ahora.

No creo que el problema fuera su transparencia. Han hecho un trabajo increíble al ser transparentes. Creo que el problema es que están tomando decisiones importantes sin saber qué piensa la comunidad al respecto. Sé que es imposible diseñar por comité, pero tal vez deberían haber documentado la lista de pros y contras que revisaron y la presentaron a la comunidad para algo tan fundamental como este cambio. Ojalá publiquen ese tipo de información pronto, pero, aun así, parece que la decisión ya está tomada.

Esto afecta a los primeros usuarios más que a nadie.

JSON se lee bien, pero solo cuando es simple. </system> es más fácil de entender que ]} en mi opinión.

La mayoría de los comentarios razonables aquí se hacen eco de mis propios pensamientos con respecto a la descarga / carga de proyectos y la gestión de dependencias que no necesitan la verbosidad inherente a XML.

¿Debería ser realmente una discusión sobre JSON vs. XML? Realmente no importa en mi humilde opinión
(seguro, personalmente me gusta más JSON que XML, pero esto no es importante)

Lo que realmente me gusta de ASP.NET Core es que es bastante abierto e independiente de Visual Studio y cualquier otro IDE. Si todavía se da, no tengo ningún problema con esta decisión.

Hay mucha discusión tóxica sobre este tema, que creo que está causando que mucha gente pierda de vista. El argumento general parece ser "¡MSBuild es malo!" pero no se está logrando una comprensión suficiente de lo que es bueno / malo en ambos enfoques.

Para todos los que afirmen que esto es un "paso atrás", tengan en cuenta que, aunque volverá a "csproj", no serán los mismos que los archivos csproj que hemos tenido durante años. Por un lado, han dicho claramente que no verá una lista de archivos en el "nuevo" formato csproj. El principal beneficio y la razón principal por la que a la mayoría de la gente le ha gustado el formato project.json es que no tiene esta lista de archivos.

De inmediato, esa es una diferencia inmediata. Eche un vistazo a xproj hoy y tendrá una idea de lo que puede esperar del "nuevo" csproj. Será un poco más grande, pero solo porque tendrá algunas propiedades adicionales tomadas de project.json. La verdadera discusión no es ni debería ser sobre "qué tan malo es MSBuild", sino sobre lo que quiere ver en el nuevo csproj y lo que quiere que quede en un archivo .json.

@dustinmoris eres injusto, creo que la comunidad agradeció la mayoría de los cambios, excepto este. Este nos está llevando hacia atrás, y ya están hablando sobre cómo lo harán sin ninguna idea del por qué. Hacen que parezca que la decisión es definitiva, por lo que no hay lugar para que la comunidad pueda presentar una propuesta mejor.

Y sí, editamos los archivos del proyecto directamente y lo estábamos haciendo dolorosamente antes de project.json. Msbuild tiene que ver con el conocimiento tribal y hace que dominarlo sea un poco difícil.

Y el "facilitará la migración de .net 4.5 a .net core" parece un poco deshonesto. Este definitivamente no es el punto de dolor ...

no será el mismo que los archivos csproj que hemos tenido durante años.

¿Será XML? Sí, eso pensé.

El principal beneficio y la razón principal por la que a la mayoría de la gente le ha gustado el formato project.json es que no tiene esta lista de archivos.

¿En base a qué información dices esto? Quiero decir, no tener la lista de archivos es una gran ventaja, pero de ninguna manera es la única para mí.

Eche un vistazo a xproj hoy y tendrá una idea de lo que puede esperar del "nuevo" csproj

Hoy no tengo xproj. ¿Por qué necesitaría algo así?

La verdadera discusión no es ni debería ser sobre "qué tan malo es MSBuild"

¿Por qué no debería ser esa la discusión? Turfing MSBuild fue un gran punto a favor para mi adopción de .NET Core. El 20% de los encuestados en mi encuesta (aparentemente) poco científica, con cámara de eco y sesgada está de acuerdo en que está fundamentalmente rota.

@shederman, tu respuesta es exactamente el tipo de discusión tóxica a la que me refiero. Solo está haciendo afirmaciones genéricas (como "¡MSBuild es malo!") Pero no las respalda con ningún tipo de discusión constructiva.

¿Será XML? Sí, eso pensé.

Si. ¿Y? Si su problema es que no le gusta _XML_, entonces es justo. Si cree que JSON es superior a XML, continúe y explique sus razones, pero eso no tiene nada que ver con la _estructura del proyecto_ y todo lo que tiene que ver con la sintaxis. Desafortunadamente para usted, tanto XML como JSON tienen su lugar en el mundo, hay ventajas y desventajas distintas para ambos y nunca habrá una respuesta "correcta" definitiva sobre cuál es mejor. Nuevamente, si yo fuera usted, me concentraría en cuáles serían las diferencias en la _estructura del proyecto_ con la mudanza.

¿En base a qué información dices esto? Quiero decir, no tener la lista de archivos es una gran ventaja, pero de ninguna manera es la única para mí.

Nunca dije que fuera el único beneficio, simplemente dije que era, con mucho, el principal beneficio. Mire cualquier discusión sobre el formato project.json que se remonta a meses atrás y lo primero de lo que habla la gente es de lo pequeño y simple que es. Eso no se debe a que JSON sea sintácticamente más limpio, se debe a la eliminación de la lista de archivos del proyecto. La mayor ventaja que la gente menciona es que se fusiona bien y se fusiona bien porque no incluye un montón de referencias de archivos.

Hoy no tengo xproj. ¿Por qué necesitaría algo así?

Toda esta discusión trata sobre el formato de archivo de proyecto más nuevo, si no está dispuesto a comparar el panorama actual, entonces su opinión será desinformada.

¿Por qué no debería ser esa la discusión? Turfing MSBuild fue un gran punto a favor para mi adopción de .NET Core. El 20% de los encuestados en mi encuesta (aparentemente) poco científica, con cámara de eco y sesgada está de acuerdo en que está fundamentalmente rota.

Debido a que en realidad no está discutiendo _MSBuild_, está discutiendo la forma en que Visual Studio ha manejado históricamente los proyectos de MSBuild, que Microsoft mismo ha admitido que es deficiente. En realidad, MSBuild ya admite casi todo lo que se requiere, incluido no tener que enumerar todos los archivos de un proyecto.

Más concretamente, todo lo que ha hecho hasta ahora en esta discusión es gritar y gritar que no le gusta XML, pero todavía tengo que verle presentar argumentos reales a favor o en contra más allá de "Simplemente no se fusiona como bueno ", que como he dicho varias veces ahora se reduce generalmente a la cantidad de archivos enumerados en un csproj" antiguo ". Si te hubieras molestado en mirar el formato xproj, verías que es bastante pequeño y Daniel dijo durante el standup que el "nuevo" formato csproj tendría aproximadamente el mismo tamaño que el archivo project.json actual, así que de nuevo, ¿qué ¿el problema? Hace afirmaciones audaces, pero no las respalda en absoluto.

@neoKushan , pronto deberías obtener algún tipo de premio de Microsoft al defenderlos sin una buena razón. Llegue al punto real de que esta es la peor decisión tomada por la puerta trasera. Recomiendo volver a hacer asp net close source y permitir que Microsoft y sus seguidores, como usted, decidan lo que quieren sin preguntar a los miembros de la comunidad de open source.

@abcplex ¿Vas a contribuir con algo a la conversación que no sean insultos y señalar con el dedo?

Hasta ahora, no ha hecho más que quejarse del cambio sin mencionar una sola razón de cuál es su problema real.

@neoKushan, el punto más importante es que no es el momento para este tipo de cambio, hace solo un mes para RTM. Hacer este cambio en este momento no tiene ningún sentido.

@abcplex El cambio no se está produciendo en RTM. Va a ser un cambio gradual posterior a la RTM . Todo lo que sucede en RTM es que su xproj cambia de nombre a csproj; literalmente, no se realizarán cambios y los cambios se realizarán en etapas, y las herramientas migrarán sus cambios por usted.

Acepte que JSON vs XML (vs XAML, como en la publicación de blog Standup que algunas personas están pidiendo) es una distracción de lo que debería ser el mérito de tener algún tipo de compatibilidad con las herramientas anteriores.

Y yo diría que esta es una forma de pensar muy equivocada. Nos guste o no, csproj y MSBuild siguen la tradición de ant, que consiste en instruir a la cadena de herramientas sobre cómo construir un proyecto, en lugar de definirlo. Son cosas muy diferentes, pero esta herencia parece darle poder de "definición" al proyecto, porque ahora podemos aplicarle la lógica, y así sucesivamente. Eso hace que las cosas sean increíblemente complicadas.

Con el viejo mundo, en numerosas ocasiones he visto archivos de proyectos rotos simplemente porque una línea que "necesitaba estar en la parte inferior" se movió hacia arriba, o alguien se metió con una variable de entorno y de repente estábamos sacando el archivo .targets incorrecto. La misma noción de que un elemento de primer nivel (hijo de raíz) depende del orden en una sintaxis declarativa está completamente rota. Esa es la tierra de MSBuild y csproj. Este es el legado que traemos aquí. Ahora, para entender un csproj, hay que "ejecutarlo" y ejecutarlo exactamente como lo haría MSBuild. Sí, MSBuild es de código abierto, pero eso en realidad no está arreglando nada. Todavía introduce una dependencia única y forzada. Todavía se basa en archivos de objetivos mágicos que se encuentran ... en algún lugar.

Un archivo de proyecto debe tener varias cualidades que lo hagan independiente de la forma de la cadena de herramientas que una tienda determinada decida utilizar:

• Debe ser editable / legible por humanos
• Debería permitir comentarios
• Debe ser declarativo
• Debe ser autónomo
• Debe estar diseñado para reducir los conflictos de fusión / simplificar la fusión, si es posible
• Debe ser completamente documentable (con el principio de autocontención que se aplica a la documentación).
• Debe ser independiente de la herramienta

Y el "facilitará la migración de .net 4.5 a .net core" parece un poco deshonesto. Este definitivamente no es el punto de dolor ...

De acuerdo al 100%. Permítanme aclarar cuáles han sido los desafíos para nosotros: las únicas dificultades hasta ahora con la migración de bases de código ha sido la pérdida de ciertas bibliotecas de clases .NET (mirándolo System.Drawing), la reticencia por parte de los equipos de Microsoft en el soporte de .NET core (mirándote DocumentDB) y los cambios de última hora estándar que se pueden esperar entre las versiones principales.

En ningún momento project.json fue un problema. De hecho, ese fue uno de los beneficios. Lo mismo ocurre con poder volcar MSBuild a un detalle invisible que ocurre mágicamente cuando Ctrl + Shift + B.

@neoKushan

1. No me gusta XML. Es un mal formato para archivos de proyecto y configuración. Fue una mala idea cuando se introdujo durante la fase "XML para todo", y ahora es una mala idea.
2. Encuentro que los archivos JSON se fusionan mucho mejor que los archivos XML. Acepto que esta es una opinión, pero es mía y está basada en mis experiencias.
3. Estoy usando vscode que no necesita y no usa archivos xproj. _Ese_ es mi panorama actual, y no quiero ni necesito un archivo xproj que no significa nada para mí.
4. No, estoy hablando de MSBuild. He hecho muchas cosas con MSBuild y Team Build. Nunca han sido divertidos, y nunca han sido fáciles, y siempre han implicado luchar con el cerdo en el barro. Odio MSBuild, y ciertamente no estoy solo.
5. MSBuild dificulta incluso las tareas sencillas. Le sugiero que busque alternativas y no se deje vencer por MSBuild. Especialmente, observe la forma en que funcionan gulp y sbt.

@shederman

No me gusta XML. Es un mal formato para archivos de proyecto y configuración. Fue una mala idea cuando se introdujo durante la fase "XML para todo", y ahora es una mala idea.

Nada de esto explica _por qué_ es una mala idea.

Encuentro que los archivos JSON se fusionan mucho mejor que los archivos XML. Acepto que esta es una opinión, pero es mía y está basada en mis experiencias.

He tenido fusiones de .json de pesadilla y fusiones de .xml de pesadilla, tampoco soy particularmente querido cuando se trata de fusiones. En mi experiencia, las posibilidades de una combinación problemática aumentan con el _ tamaño_ del archivo, independientemente del formato.

Estoy usando vscode que no necesita y no usa archivos xproj. Ese es mi panorama actual, y no quiero ni necesito un archivo xproj que no significa nada para mí.

Eso no significa que no pueda ir y mirar el archivo xproj actual para tener una idea de qué es. Al no hacerlo, estás haciendo el equivalente de meterte los dedos en los oídos, cerrar los ojos y decir "La la la".
Para decirlo de otra manera, puede estar molesto por el hecho de que está ocurriendo un cambio y lamentarse, sin lograr nada, o puede participar en la conversación real y ayudar a dirigir el resultado de esto.

Por ejemplo, una cosa que aún no está decidida es si las dependencias nuget pasarán a formar parte del csproj, o si se convertirá en nuget.json; ahí está su preferencia. Una vez que tenga sus listas de dependencias en un archivo .json, ¿qué queda en el csproj? ¿Con qué frecuencia cambiará eso? ¿Cuán difícil será _eso_ fusionarse?

Personalmente, preferiría que todo estuviera contenido en un solo archivo de proyecto, pero puedo ver el atractivo y los beneficios de separar nuget del proyecto en sí. Hay pros y contras para ambos y quizás la mejor solución es permitir ambos, tener un csproj con una lista de dependencias pero también permitirle apuntar a un archivo .json con sus dependencias en su lugar. Lo mejor de ambos mundos y todos ganan, a expensas de cierta complejidad adicional al propio MSbuild.

No, estoy hablando de MSBuild. He hecho muchas cosas con MSBuild y Team Build. Nunca han sido divertidos, y nunca han sido fáciles, y siempre han implicado luchar con el cerdo en el barro. Odio MSBuild, y ciertamente no estoy solo.

Habiendo tenido que lidiar con las definiciones de compilación basadas en XAML de TFS, al menos puedo estar de acuerdo con usted en (algunas de) esta.

MSBuild dificulta incluso las tareas sencillas. Le sugiero que busque alternativas y no se deje vencer por MSBuild. Especialmente, observe la forma en que funcionan gulp y sbt.

Entonces le sugiero que deje de tirar sus juguetes del cochecito y participe activamente en la discusión sobre cómo debería lucir _en realidad_ la "nueva" estructura del proyecto. Imagine un futuro en el que tenga que lidiar con un archivo de proyecto basado en XML, ¿cómo le gustaría que se vea realmente ese archivo de proyecto?

Imagina un futuro en el que tendrás que lidiar con un archivo de proyecto basado en XML

Um. Bien, entonces debo imaginar un futuro que no quiero y explicarte cómo funcionaría. Um, no, no lo creo. ¿Qué tal si nos fijamos en algunos sistemas de construcción más innovadores y modernos? ya sabes, los que dejaron XML en el pasado distante.

Qué tal si:

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

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

O tal vez

organization := "com.devdaily"

name := "ScalatraTest1"

version := "0.1.0-SNAPSHOT"

scalaVersion := "2.9.1"

seq(webSettings :_*)

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

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

Oh, sí, que se ha vinculado a xproj es mucho mejor. Agradable, claro y conciso. Y expresivo, no te olvides de expresivo. ¿Para qué es ese ProjectGuid? Y me encantan los 90 caracteres para configurar la versión de la herramienta. ¿Y el DnxInvisibleContent? ¿Es útil que mi sistema de compilación lo sepa? ¿Qué archivos no mostrar en el IDE que no estoy ejecutando?

Te sugiero que dejes de tirar tus juguetes del cochecito.

No quiero :-)

No, ya terminé. Tuve una larga charla con Immo, y he terminado de pelear esta batalla. Todos tienen su opinión parcial y nadie quiere escuchar el escandaloso concepto de que su camino puede no ser perfecto para todos.

[Editado para eliminar la petulancia]

@shederman : aquí muestra archivos de definición de compilación ; Quiero alejarme de las definiciones de compilación como una definición de proyecto. Hay espacio para definir los detalles estáticos sobre un proyecto / artefacto a generar independientemente de las instrucciones sobre cómo generarlo. Que combine los dos es uno de los principales problemas al usar archivos de MSBuild como archivos de proyecto.

Quiero poder especificar solo la información necesaria para describir los artefactos que se generarán y las dependencias y la cadena de herramientas que se usarán, y el diseño de varios elementos que componen el proyecto en el disco. Todo lo demás debería estar separado. Si desea utilizar MSBuild bajo el capó, adelante. Lo mismo ocurre si prefiere gulp, babel o lo que sea. Para mí, eso es para lo que se configuró project.json. (Sin embargo, no era un fanático de la capacidad de definir comandos allí)

Sí, eso tiene sentido. Esa fue una de las cosas que me gustó de project.json. Definió el "qué", no el "cómo". Al poner demasiadas cosas en un archivo, hacemos que el archivo sea demasiado complejo, especialmente si nuestro IDE es estúpido. Y eso no es necesario para los editores y los IDE simples.

Desde una interfaz de usuario de poca ceremonia como VS Code, no hay mucha necesidad de un sistema de proyecto. Todo es construcción. Mucho es declarativo, diciendo qué se debe construir y metadatos. Algunos pueden ser imperativos, diciendo qué pasos deben realizarse.

Sí, el mayor problema de MSBuild es que intenta hacerlo todo en un solo sistema.

Supongo que lo que no estoy captando es esto: muéstreme algunos casos de uso que se mejoran al usar MSBuild como el sistema de proyecto en lugar de simplemente hacer que project.json funcione. No lo veo Quizás mis casos de uso son demasiado simples, así que muéstrame algunos.

@shederman Las notas de pie mencionan la necesidad de poder compartir archivos fuente entre proyectos

Entonces ... este es un proyecto de código abierto, y sé que Microsoft es "los poderes fácticos", pero si esto es tan importante para la gente, entonces - y entiendo que estoy haciendo una pregunta ignorante aquí - cuánto tiempo ¿/ Esfuerzo / Energía tendría que gastarse para permitir que .NET Core continúe usando project.json como alternativa a MSBuild? Si suficientes personas contribuyen y el código es lo suficientemente bueno, ¿por qué MS no lo aceptaría en este proyecto? Parte de la belleza (y la ruina) de Open Source es la amenaza de bifurcar el código si los mantenedores principales rechazan demasiado de lo que ofrecen otros. Parte del objetivo de que el código sea de código abierto no es solo para mirar, sino para modificar y mejorar.

Mi opinión personal sobre el cambio es que tiene que ver con Xamarin, ya que se trata de planes futuros. Además, en las recientes reuniones de pie, creo que les escuché decir que quieren que la creación de aplicaciones de consola sea un ciudadano de primera clase. Recuerde que originalmente, el nuevo .NET (ASP.NET 5 + DNX) estaba enfocado en construir aplicaciones web, ahora se trata de más. Todo esto ha ocurrido hace relativamente poco tiempo, los equipos de .NET y ASP.NET se fusionaron, y también la compra de Xamarin. Llegaron a la conclusión de que necesitan un mejor sistema de proyectos para admitir estos múltiples escenarios (y nuevos escenarios futuros sobre los que no especularé aquí), y también quieren enviar .NET Core pronto. ¿Qué hacer? ¿Ignore por completo el MSBuild preexistente que ya puede manejar lo que se requiere y comience desde cero? Lo siento, sé el camino que elegiría.

Una buena parte de la preocupación parece estar en torno a la fusión, PERO si el archivo del proyecto no contiene los nombres de los archivos en el proyecto, y si las dependencias se insertan en un archivo de configuración separado, el problema de fusión debería desaparecer, ya que los archivos del proyecto deberían cambiar. con relativa poca frecuencia.

Solo es mi opinión

El problema de la fusión es solo un problema. Alejarse de MSBuild es otra. ¡Un resultado loco de este escenario es que ahora van a dedicar tiempo y esfuerzo a portar MSBuild a Linux y OSX! Imagina eso.

Entiendo sus razones, pero sus razones no funcionan para mí en absoluto y no funcionan para mucha gente. Hicimos inversiones basadas en garantías firmes sobre la dirección que estaban tomando, y han retrocedido sin responsabilidad, y nada más que una indicación de que tal vez deberían haber _comunicado_ mejor la decisión. Están tomando una decisión sobre project.json en función de los casos extremos que admite MSBuild y de lo difícil que sería admitir esos casos extremos. Bueno, eso significa que _nunca_ dejará de usarse, porque nadie en su sano juicio apoyaría todos esos casos extremos. Ciertamente, nadie que realice proyectos ASP.NET necesita esos casos extremos.

La bifurcación es una posibilidad, pero dado lo grande e integrado que es todo, es una perspectiva desalentadora considerar incluso aprender el código relevante. La realidad es que este no es realmente un proyecto de código abierto, es un proyecto de Microsoft, y han tomado una decisión corporativa sin nuestra participación, y debemos aguantarlo y aceptarlo. Me ha quedado claro que básicamente no hay posibilidad de que nunca lo reconsideren, sin importar la oposición que haya.

Entonces, o gastamos el esfuerzo y bifurcamos el sistema de compilación project.json, o cambiamos a otro sistema de compilación (¿FALSO?), O lo aguantas, o usas otra plataforma. Creo que he enumerado todas las opciones allí.

@shederman MSBuild ha sido de código abierto desde principios de 2015, y las compilaciones se están transmitiendo a OSX / Ubuntu, por lo que no creo que sea tanto trabajo como podría pensar portar (https://github.com/Microsoft/msbuild) , al navegar por el repositorio, parece que OSX se estaba construyendo bien en marzo, por ejemplo.

Oh querido. Me preocupa si deberíamos hacer esto, y ellos se han ido y lo han hecho ...

Siéntete un poco como alguien que mira al Monstruo de Frankensteins precipitarse en la distancia. Interesado, intrigado, preocupado y más que un poco disgustado :-)

@darrelmiller Las notas de pie mencionan la necesidad de poder compartir archivos fuente entre proyectos

¿En serio? ¿La gente todavía hace eso? Quiero decir, solía hacerlo para AssemblyInfo.cs, y en la Edad Media, poníamos nuestra clave Strong Name en un archivo fuente compartido.

Bien, ese es un caso de uso, pero ahora realmente quiero escuchar un caso de uso para el caso de uso. Intrigado.

@shederman

Um. Bien, entonces debo imaginar un futuro que no quiero y explicarte cómo funcionaría. Um, no, no lo creo

Todo lo que tienes que hacer es aceptar XML en lugar de JSON, para ver cuáles podrían ser los beneficios, pero no estás dispuesto a jugar ese juego porque todo lo que quieres hacer es hablar sobre lo malo que es XML sin decir realmente por qué .

Oh querido. Me preocupa si deberíamos hacer esto, y ellos se fueron y lo hicieron ...

Han estado "yendo y haciéndolo" literalmente durante _ años_ ahora. Hablaron de .net de código abierto hace años, dieron hojas de ruta y dejaron en claro que se trataba de ejecutar en cualquier plataforma eventualmente, para cualquier caso de uso.

Estás bastante molesto por este cambio y sospecho que la mayoría de las personas molestas por el cambio son todos desarrolladores web, pero eso es solo una pequeña parte del ecosistema .net, hay un enorme ecosistema de servicios, desarrolladores móviles y en la nube que tienen enormes bibliotecas de código que quieren poder migrar a .net core. Nos guste o no, project.json simplemente no funciona actualmente para todos esos modelos. Dices "haz que funcione" pero vas a terminar con otro archivo de proyecto desordenado, excepto uno que no tiene una estructura obvia y claramente definida y, peor aún, sin comentarios. Ese último punto es razón suficiente para repensar project.json.

Oh, sí, ese xproj al que te vinculaste es mucho mejor. Agradable, claro y conciso. Y expresivo, no te olvides de expresivo.

Al menos finalmente lo has mirado. ¿Solo tomó qué, 72 comentarios en este número antes de que siquiera se molestara? Le sigo diciendo esto, pero no lo está entendiendo: en lugar de quejarse de lo terrible que es MSBuild, hable de por qué es terrible .

El problema de la fusión es solo un problema. Alejarse de MSBuild es otra.

¿Por qué es esto un problema? Odias MSBuild, lo entendemos, pero ¿qué es lo que odias de MSBuild aparte del hecho de que _dares_ usar XML?

¡Un resultado loco de este escenario es que ahora van a dedicar tiempo y esfuerzo a portar MSBuild a Linux y OSX! Imagina eso.

¡Estás bien! Va a ser terrible, poder desarrollar cualquier tipo de aplicación .net en cualquier plataforma que desee, utilizando cualquier IDE que desee. ¡Piensa en los niños!
¿Cómo se atreve Microsoft a dedicar tiempo a abrir su trabajo y trasladar sus herramientas a otras plataformas en lugar de invertir en su propia tecnología de código cerrado?

Entiendo sus razones, pero sus razones no funcionan para mí en absoluto y no funcionan para mucha gente.

¿Pero tal vez funcionen para mucha más gente que tú?

Hicimos inversiones basadas en garantías firmes sobre la dirección que estaban tomando, y han retrocedido sin responsabilidad, y nada más que una indicación de que tal vez deberían haber comunicado mejor la decisión.

¿A qué _dirección_ te refieres? El objetivo siempre ha sido .net en todas partes, "Cualquier desarrollador, cualquier aplicación, cualquier plataforma" es el mantra del día y no hay absolutamente nada en este cambio que afecte eso. Han declarado claramente que sus objetivos son mantener el archivo del proyecto pequeño, simple, legible y editable por humanos sin un IDE. No te están quitando nada. Es posible que tenga que lidiar con un poco de XML, un gran grito, si eso significa que .net es una experiencia de primera clase para dispositivos móviles, la nube y la web, entonces vale la pena.

Están tomando una decisión sobre project.json en función de los casos extremos que admite MSBuild

Esto va más allá de los casos de _edge_, es ridículo incluso sugerir que project.json es casi perfecto.

Ciertamente, nadie que realice proyectos ASP.NET necesita esos casos extremos.

Supongo que este es el meollo del problema: no te preocupas por nadie más que tú mismo, un desarrollador de asp.net. Es bastante justo, pero de nuevo te diría: acepta que otros desarrolladores son importantes y, en lugar de simplemente levantar los brazos, trabaja para convertirlo en el mejor sistema posible. Eso no significa inventar una sintaxis arbitraria para un marcado completamente diferente, significa aceptar que la imagen es más grande que usted y trabajar con otros para que sea excelente para todos.
Como sigo diciendo, si nuget.json enumeró todas sus dependencias, ¿qué queda? ¿Cuál es el problema de definir algunos campos bastante estáticos en elementos con nombre de XML?

La realidad es que esto no es realmente un proyecto de código abierto.

Como han dicho otros, ser de código abierto no significa hacer todo lo posible ante unos pocos quejosos. Aceptan solicitudes de extracción, vayan a escribir algo mejor.

dado lo grande e integrado que es todo, es una perspectiva desalentadora considerar incluso aprender el código relevante.

De acuerdo, básicamente estoy leyendo esto como "No entiendo el panorama general y no quiero comprender el panorama general, sin embargo, todavía me quejaré porque afecta a mi pequeña burbuja sin tener en cuenta las implicaciones mi burbuja tiene sobre los demás ".

Entonces, o gastamos el esfuerzo y bifurcamos el sistema de compilación project.json, o cambiamos a otro sistema de compilación (¿FALSO?), O lo aguantas, o usas otra plataforma. Creo que he enumerado todas las opciones allí.

O ... y quiero decir que esto es solo un pensamiento loco, fuera de la caja, pero podrías intentar contribuir con algo constructivo a la conversación.

Volviendo al tema ...

Lo he pensado más y ahora me inclino a que project.json se convierta en nuget.json, manteniendo la gestión de dependencias como está ahora. Funciona bien ahora, el intellisense ya está ahí y es consistente con cosas como gulp y npm.

Deje que csproj simplemente defina las partes estáticas.

Sin embargo, la desventaja de este enfoque que puedo ver es que no estoy seguro de qué tan bien funcionaría al apuntar a múltiples marcos, realmente no creo que tenga sentido poner eso en nuget.json pero nuget.json es todavía tendré que saberlo.

project.json no es solo un archivo json.
csproj no es solo un archivo XML.

En mi humilde opinión, muchas personas, como yo, estaban emocionados de ver a Microsoft, más precisamente al equipo de Asp.Net,
liberándose de códigos / conceptos / sistemas / herramientas / apariencias heredados muy antiguos / ...

¡Esto nos dio 'esperanza'!

Desarrollo Asp.Net desde los primeros bits de vista previa. Sobre todo me encanta trabajar con él. Pero después de 15 años,
el material "antiguo", como XML, se siente realmente pesado y desactualizado. La percepción ES importante.

Sin XML y al menos usando JSON en su lugar, mi 'felicidad como desarrollador' es mucho mayor.
Puedo trabajar con cosas que el resto del mundo ha decidido usar. Mi IDE favorece esas cosas sobre los formatos heredados.
Ya no tengo que pagar "El impuesto sobre soportes angulares".

Eliminar project.json no es gran cosa, pero hacerlo a puerta cerrada casi en el último momento mata esa 'esperanza' al instante.

De repente, esto ya no se siente como un proyecto de código abierto.

fyi: "Asp.Net Core" tiene muchas características fantásticas. Sobre todo me encanta.
El equipo de Asp.Net es excelente y no podría estar más orgulloso de ser un desarrollador de Asp.Net.

Pero estoy herido. Quizás no soy el único.

Solo mis 2 centavos.

Creo que casi todos podemos estar de acuerdo en que msbuild (especialmente en cómo lo usa VS) no es perfecto, y aunque estaba entusiasmado con project.json, se trataba más de que MS arreglara muchos de mis puntos débiles y, para ser honesto, siempre y cuando probablemente no me importe mucho cómo lo hicieron.

• Las fusiones de csproj no funcionan tan bien, me encuentro en la necesidad de arreglar manualmente una fusión rota cada dos semanas. Eliminar la lista de archivos del csproj ayudaría mucho aquí.
• Las referencias de NuGet y las referencias de proyectos no siempre se alinean, nuevamente, podría deberse a fusiones rotas. De cualquier manera, es molesto diagnosticar y corregir.
• De vez en cuando necesito conectarme al proceso de compilación (no estoy seguro de cómo se supone que funcione en project.json) pero toda la necesidad de descargar / cargar hace que la depuración del script de compilación sea un proceso doloroso.

Si encuentran una manera de arreglar esos 3 elementos, probablemente no me quejaría tanto de los archivos csproj.

@neoKushan

todo lo que quiere hacer es hablar sobre lo malo que es XML sin decir realmente por qué

No es del todo justo, también quiero hablar sobre lo malo que es MSBuild :-)

Estoy seguro de que en realidad _he_ dicho por qué no me gusta XML para archivos de compilación, pero déjame intentarlo de nuevo. XML es detallado, es feo, es mejor para las herramientas que para la edición manual, y no disfruto la experiencia de fusionarlo. Se usó para MSBuild, porque en ese entonces la industria pensaba que XML podía usarse para todo. Seguimos adelante desde entonces. Bueno, en algunos lugares.

peor aún - sin comentarios

Creo que varias personas han ofrecido alternativas aquí. HJson es solo una opción. ¡Hurra! No tenemos que repensarlo después de todo ;-)

Estás bastante molesto por este cambio

Para ser justos, estoy muy molesto por la forma en que se realizó este cambio en una sala cerrada sin considerar ni comprometerse con la comunidad que había recibido el apoyo anterior y muy firme para project.json al pie de la letra. ¡Chico, no volveré a cometer ESE error!

No me malinterpretes, no me gusta XML, no me gusta MSBuild. Pero odio que me digan que adopte algo que realmente amo y que luego me digan en el último minuto que me lo están quitando. ¡No muevas mi queso!

Sospecho que la mayoría de las personas molestas por el cambio son desarrolladores web.

Umm, sí, eso sería porque son los únicos desarrolladores a los que les ofreciste project.json. En otras noticias, los desarrolladores de Swift tampoco están molestos por la decisión. Quiero decir, piensa en lo que estás diciendo aquí:

1. Solo los desarrolladores web tienen esta nueva función
2. Muchos de ellos estaban realmente molestos cuando se lo quitamos.
3. Nadie más tiene que usarlo
4. Las personas que no lo usaron no están molestas porque se lo quitaron.
   ergo, todos los demás desarrolladores no lo querrían.

Creo que necesitas echar un vistazo a la calidad de tu pensamiento, y eso es lo que traté de interrogar durante bastante tiempo y no llegué a ninguna parte. La falta de información sobre el pensamiento, y el hecho de que las partes relevantes se hayan cerrado, me indica que el pensamiento puede haber sido sospechoso.

¿Y a qué se refiere con "desarrolladores web"? ¿Estás pensando en un pequeño sitio web para una pequeña empresa? ¿Qué tal una pila de microservicios que respalden un negocio de gestión de activos con decenas de miles de millones de dólares bajo gestión? Claro, también hay un sitio web. Pero eso es aproximadamente el 10% del sistema. Ah, y sí, en realidad también está dirigido a la nube, así que tal vez estemos hablando de "desarrolladores de la nube".

Parece que ni siquiera comprende cómo se utiliza la tecnología sobre la que está tomando decisiones apresuradas o quién lo utiliza.

¿Qué es lo que odias de MSBuild además del hecho de que se atreve a usar XML?

Es demasiado complicado
Es un desajuste de impedancia, empujando la lógica basada en inferencias en situaciones en las que las personas están lidiando principalmente con lógica imperativa o declarativa.
Dios mío, ¿realmente ha _ mirado_ los archivos de MSBuild? De acuerdo, lo siento, dijiste además de usar XML ;-)
La forma en que se declaran las propiedades y los elementos es contraria a la intuición para cualquiera que no los use con regularidad.
Se utiliza como una herramienta de talla única que intenta realizar tareas que deberían realizarse en scripts. Clavos.
En una gran cantidad de casos, todo lo que hace en un archivo grande podría expresarse en 3 líneas de script como máximo
La basura VS que se arroja en él. Escuché que se arreglará. Esperando con cierta inquietud para ver si eso también se corta. Como se mencionó anteriormente, ahora soy un poco tímido con las promesas.

¿Qué es lo que amas tanto? Y lo más importante, ¿está dispuesto a aceptar que otros no compartan sus puntos de vista? Si es así, ¿puede admitir que "una talla para todos" podría no ser el enfoque correcto?

¿A qué dirección te refieres?

project.json es la base de nuestro nuevo enfoque de proyecto, es lo que se comunicó. Invertimos dinero real, tiempo y dolor sobre la base de ese compromiso.

¿Pero tal vez funcionen para mucha más gente que tú?

Quizás sí lo hagan. Pero si es así, ¿dónde está la evidencia de eso? Intenté interrogar el pensamiento, la toma de decisiones y la evidencia que se utilizó en esto, y no obtengo nada de nadie. Por toda la evidencia que se ha proporcionado, podría haber sacudido una bola 8 mágica por lo que sabemos.

Nadie sabe cuántos piensan de una forma u otra. De hecho, soy el único que conozco que trató de averiguarlo.

No te preocupas por nadie más que tú mismo, un desarrollador de asp.net

No muy bueno. Lo que en realidad estoy diciendo es que la afirmación es que la nueva dirección funciona para todos los casos de uso, y estoy levantando la mano y diciendo que no funciona para mí. Tú eres el que cabalga sobre toda la oposición. Yo soy el que le pregunta a la gente lo que piensan, la EM no.

En ningún momento he dicho "deshacerse de MSBuild por completo y hacer cumplir mi proceso de compilación en todos los demás desarrolladores". Usted es el que dice "deshacerse de project.json por completo y hacer cumplir MSBuild en todos los desarrolladores". Teníamos dos sistemas de compilación en todas las vistas previas y estábamos felices. Los desarrolladores web estaban contentos y los que no eran desarrolladores web estaban contentos.

Podemos discutir qué tan factible es eso, y tal vez no lo sea, pero no lo sabemos , porque nunca nos consultaron ni nos comprometieron.

Realmente amas tu argumento del medio excluido.

Aceptan solicitudes de extracción

¿En serio? Si emitimos una solicitud de extracción que dejara una herramienta de compilación no basada en MSBuild en la funcionalidad de herramientas principal, ese proyecto.json de solo lectura, ¿lo incluiría en el marco? ¿En serio?

Bien, básicamente estoy leyendo esto como ...

Vaya, leíste mucho en eso. Dios, si leo como tú, nunca terminaría un libro. Y sería bastante diferente a lo que escribió el autor.

Intente más bien, "No entiendo completamente el panorama general y estoy considerando el esfuerzo y el tiempo que implicaría hacer esto. Sería mucho mejor si tuviéramos la ayuda de los desarrolladores existentes para entregar una fracción tan significativa de su comunidad quiere, pero supongo que si no les importa lo que quieren sus usuarios, es posible que tengamos que ir por ese camino ".

¡Maldita sea! ¡Leo como tú! Excepto que en realidad se ajusta un poco mejor al texto original que tus interpretaciones un tanto histéricas.

podría intentar aportar algo constructivo a la conversación.

Bueno, en realidad pensé que estaba siendo constructivo. Después de superar el impacto inicial, traté de averiguar cuál era la base de esta decisión. Traté de averiguar cuál era el proceso de toma de decisiones. Traté de cuestionar la calidad del pensamiento que había detrás. Cuando me dijeron que la mayoría de los desarrolladores querían esto, pero no se proporcionó evidencia para respaldar esta afirmación, de hecho les pregunté , lo cual _nadie_ en el equipo había hecho por cierto.

¿Qué obtuve? Obstrucción, insultos y evasiones. Entonces, dígame, ¿por qué considera poco constructivo preguntar si alguien que tomó una decisión importante que afecta a millones hizo su tarea? ¿Y le parece constructivo o sospechoso que dicha gente se niegue a mostrar el libro de deberes?

Quiero decir, de manera realista, estos son los escenarios probables:
1) Tomó la decisión basándose en un conjunto completo de comentarios e información, y la decisión es realmente, con mucho, la mejor opción para seguir adelante. Si es así, me callaría, lo prometo. Creo que esta situación es bastante improbable debido al nivel de oposición que ha recibido y al hecho de que está ocultando la evidencia y la toma de decisiones.
2) Tomó la decisión basándose en vistas parciales, pero lo mejor que tenía en ese momento. Yo diría que la respuesta correcta sería reabrir la decisión y solicitar las opiniones que dejó fuera. Encuentro que esta es la situación más probable.
3) Tomó una mala decisión o se basó en mala información. En cuyo caso, nuevamente, debe reabrir la decisión y solicitar a la comunidad. Realmente no creo que esta sea la situación en absoluto, porque, por mucho que no me crean, respeto inmensamente a los desarrolladores de DotNetCore. Todos ellos.

Y sabe qué, si reabre la decisión, solicita las opiniones y la decisión se toma de la misma manera, ¿cuál es el daño? Y si, después de solicitar las opiniones, se da cuenta de que algunas de sus decisiones fueron defectuosas y las corrige, ¿no es eso realmente mejor ?

Vaya, en serio. ¿Podemos acabar con esto?

Pregunta simple: ¿aceptará a la oposición y volverá a examinar la decisión basándose en la nueva información?

¿O va a seguir dando a entender que las personas que no están de acuerdo con usted son locas, estúpidas, no calificadas, desinformadas o incapaces de sostener una opinión informada y válida?

Sugerencia: bifurcación de Microsoft para admitir clientes heredados de msbuild csproj. #carryOnAsNormal

También soy un desarrollador de .Net desde hace mucho tiempo, estaba trabajando con vistas previas de 1.0 antes de que marketing incluso inventara el nombre .Net. Sin perderme demasiado en la maleza, aquí está mi granito de arena.

Podría pasar el resto de mi vida sin ver otro archivo de configuración xml y ser perfectamente feliz.

No quiero configuración xml. En cualquier lugar. Alguna vez.

No me importa si el equipo corrige todos y cada uno de los puntos débiles de csproj; si todavía es un archivo de configuración xml cuando haya terminado, entonces no estoy interesado. También puedes quedarte con el sistema de proyectos .net 4.5.

En cuanto a MSBuild ... MSBuild puede morir en un incendio f'n.

Entiendo que es poderoso, y existen muchas herramientas a su alrededor, pero fuera de MS, solo los expertos en MSBuild realmente saben lo que hace o cómo funciona. Cada vez que tengo que incorporar alguna personalización al proceso de construcción, termino perdiendo de 3 a 5 días de mi vida profesional. Rara vez puedo obtener algo, incluso cosas triviales como simplemente incluir una carpeta vacía en la salida, para que funcione correctamente en VS, VS Publishing y mi servidor CI, todo al mismo tiempo.

Lo entiendo ... si no tiene tiempo para construir un buen reemplazo para MSBuild para el período de tiempo de asp.net core 1.0, entonces seguro ... idear una manera de continuar aprovechando MSBuild hasta el asp.net core 2.0 ciclo; pero al menos sigue trabajando en la dirección de reemplazar esa mierda con algo con lo que el resto de nosotros podríamos trabajar.

Mientras tanto, intente mantener la mayor cantidad posible de la configuración en json. No me importa específicamente si es project.json o algo nuevo y mejor. Si es necesario, haga que las herramientas generen archivos MSBuild heredados sobre la marcha cuando / si es necesario, péguelos en una subcarpeta en algún lugar o algo.

Lo que no quiero es que mi sistema de archivos se vea así:

• bower.json
• package.json
• nuget.json
• todo-lo demás.json
• microsoft-old-ass.xml.csproj

Además, ¿podría arreglar el límite de longitud de ruta de 260 caracteres ... por favor ... sí, sé que tiene mucho que ver con Windows, pero en serio ... es 2016..

PD. Si se va a llevar en ignorar la oposición, puede usted por favor proporcione la siguiente:

• Cómo obtendríamos acceso a los canales de holgura del desarrollador de herramientas de compilación
• Una vista de alto nivel de la arquitectura y el código actuales, y dónde se realizarán los cambios para pasar a MSBuild / xproj para que podamos planificar nuestro enfoque para mantener los bits que queremos e integrar bien.
• Garantía de que se aceptarán solicitudes de extracción de horneado en herramientas basadas en project.json si cumplen con los criterios de calidad
• Garantía de que, si se cumplen los criterios de calidad, podemos incluir compatibilidad con "dotnet build" para project.json completo, así como plantillas simples de ASP.NET y, potencialmente, algunas plantillas para tipos de proyectos más estándar.

"Sea constructivo", "no contribuya, no tenga voz". Bueno, obtienes lo que pides ...

@ Mike-EEE, ¿quieres hacer serializaciones Xaml para SimpleUseCaseBuild?

Después de leer todo esto llegué a estas conclusiones:

• project.json trajo muchas mejoras. Nada de esto hubiera sido posible si .net y asp.net core hubieran estado vinculados al código y las herramientas heredados
• project.json (y json) no es perfecto
• xml vs json vs cualquier lenguaje de serialización son estériles. Las discusiones sobre cómo aprovecharlos para responder a los desafíos centrales de .net serían más interesantes
• volver a msbuild es recuperar el legado y probablemente significa que no veremos más mejoras en el sistema del proyecto, porque es probable que los equipos .net pierdan algo de su libertad

Espero que los equipos de .net respiren hondo, detengan esto un poco, recopilen comentarios (y consideren la adopción y percepción de esta nueva pila) y desafíen el enfoque de msbuild (que podría no ser tan malo como algunos de nosotros pensamos) con algunas alternativas. Creo que es necesario apresurarse.

LOL @shederman, ¿en qué me has metido ahora? : smile: ¡Y que discusión! Realmente increíble.

xml vs json vs cualquier lenguaje de serialización son estériles. Las discusiones sobre cómo aprovecharlos para responder a los desafíos centrales de .net serían más interesantes

Sí, para mí, lo importante es el modelo de respaldo que se usa para describir los proyectos y / o lo que hacen, y parte de esta conversación ha tocado eso. Me gustaría ver un modelo de proyecto / api mejorado que sea más fácil de describir y trabajar (sin importar el formato en el que se describe, aunque sí, lo hago: corazón: ¡mi Xaml!). Tengo una discusión abierta sobre el repositorio de MSBuild aquí (https://github.com/Microsoft/msbuild/issues/613) con respecto a esto y también sobre el sistema de proyectos de Roslyn (https://github.com/dotnet/roslyn-project -system / issues / 37) también, si está interesado.

Hay muchos puntos realmente buenos aquí, y yo personalmente estoy cavando la energía, "no constructiva" o de otro tipo. Creo que todos aquí tienen el corazón en mejorar MSFT y aprovechar al máximo lo que se está produciendo. : +1:

Mis 2 centavos:

Creo que hay dos tipos de personas que discuten este cambio:

• desarrolladores que han estado usando VS y .NET para construir _varios_ tipos de proyectos y tienen que apoyar esos proyectos durante mucho tiempo
• desarrolladores que no tienen tanto equipaje y quieren un marco ASP.NET Core nuevo, limpio y elegante, multiplataforma

Personalmente, estoy en la primera categoría, así que quiero que el nuevo ASP.NET Core sea lo más compatible posible con otros tipos de proyectos VS, y pasar a la solución csproj / msbuild "antigua" es una victoria para mí (+ mi equipo y probablemente muchos otros desarrolladores). De esta forma la transición sería mucho más suave y clara. Tal vez la gente de la segunda categoría no esté de acuerdo conmigo (o simplemente no les importa).

El único problema importante que veo ahora es cómo se definen y se hace referencia a los paquetes NuGet. Es una molestia tener que mantener los archivos packages.config y csproj (como @JulianRooze ya mencionó en https://github.com/aspnet/Home/issues/1433#issuecomment-218606377). Esto tiene que ser refactorizado. Idealmente, debería hacerse como @ cwe1ss sugerido en https://github.com/aspnet/Home/issues/1433#issuecomment-218519705). Fue uno de los comentarios más constructivos en este tema por cierto ...

En cuanto a la guerra santa XML / JSON ... En mi humilde opinión, XML es mejor para la edición manual que JSON. XML admite comentarios y tiene más información de contexto cuando lo mira. JSON es mejor para los datos, no para los archivos de configuración. La combinación es igualmente buena y mala para ambos formatos, depende únicamente del contenido. Si las referencias del proyecto se separaran de los archivos csproj actuales, la fusión también sería mucho más fácil ...

@Funbit tratar de categorizar a las personas no ayudará. Y no encajo en ninguna de tus categorías. Soy un desarrollador de asp.net desde v1 betas. Casi dejé de serlo hace 2 años, pero .net core me trajo de vuelta porque era borrón y cuenta nueva y lo mejor del mundo de .net y nodos.

Quiero que .net core sea un éxito, no un viejo techno corporativo sin adopción y sin comunidad.

Por mi parte, realmente no me importa esta decisión, no me importa mucho XML, y para robar una cita: "Las llaves son mejores que las llaves angulares", pero realmente no me molesta volver a csproj / msbuild: soy flexible y puedo arreglármelas.

Sin embargo, me gustaría hacerme eco de algunos de los comentarios de

La realidad es que este no es realmente un proyecto de código abierto, es un proyecto de Microsoft, y han tomado una decisión corporativa sin nuestra participación, y debemos aguantarlo y aceptarlo. Me ha quedado claro que básicamente no hay posibilidad de que lo reconsideren alguna vez, sin importar la oposición que haya.

y

Para ser justos, estoy muy molesto por la forma en que se realizó este cambio en una sala cerrada sin considerar ni comprometerse con la comunidad que había recibido el apoyo anterior y muy firme para project.json al pie de la letra. ¡Chico, no volveré a cometer ESE error!

Esto _me_me molesta, Microsoft ha hecho un gran negocio con el código abierto .NET y desea realmente involucrar y trabajar con la comunidad, obtener sus comentarios y ser un buen 'miembro' (¿socio?) De la comunidad. Pero este tipo de cosas realmente retrasa todo ese esfuerzo y le da al ecosistema .NET esa sensación "aburrida" de que el /. comunidad lo etiquetó con durante años.

Para ser justos con Microsoft, no son los únicos que hacen este tipo de cosas con un proyecto patrocinado por una empresa; ¿recuerdas la división en la comunidad de nodejs (que causó la bifurcación de io.js)? Pero creo que cuando se trata de Microsoft, es mucho peor.

Eso fue mucho más desproporcionado de lo que se pretendía inicialmente.

Eso fue mucho más desproporcionado de lo que se pretendía inicialmente.

@MaximRouiller , ¿siquiera eres desarrollador, hermano ??? :sonrisa:

@ Mike-EEE lo hago. Esperaba una discusión acalorada, pero he visto demasiados ataques personales. :decepcionado:

necesidad de poder compartir archivos fuente entre proyectos

@darrelmiller Esto me parece aterrador, porque parece implicar que la lista de archivos en .csproj está volviendo.

@lokitoth Probablemente no haya ninguna razón por la que los archivos vinculados no puedan usar comodines también.

@MaximRouiller Yo también soy culpable de acelerar y ser demasiado impulsivo y decir lo que pienso. ¡Pensé que era malo, pero @shederman sabe derribar! Ja ja. Por cierto, iba a decir que @shederman representa mi animal de codificación interno, pero eso fue antes de que supiera que había un @CodingGorilla. :risa:

Creo que tenemos que recordarnos a nosotros mismos que lo que hacemos es realmente un trabajo viene @shederman ), me ayudó a ver que tal vez no sé _todo_ (o incluso _cualquier cosa_ a veces, ¡se siente!) y tener la mente abierta sobre las cosas. Todavía fallo. Incluso cuando vi la iniciativa project.json hice todo lo posible para señalar la división que estaba creando, pero podría haber sido un poco demasiado abrasivo con la gente aquí en el repositorio al hacerlo.

De todos modos, siempre es mejor respirar hondo, (intentar) tener un espíritu humilde y recordarnos a nosotros mismos que estamos en el mismo equipo, incluso si ese equipo se ha dividido en campamentos "web" y "nativos" ahora. Puede apestar por un tiempo, pero de lo que estamos hablando aquí es algo que nos servirá durante mucho tiempo, incluso una década o más. Centrémonos en un enfoque a largo plazo y al mismo tiempo tengamos empatía por los demás y de dónde vienen.

OK ... suficiente predicación y rah-rah por el día. : stick_out_tongue: ¡De vuelta a nuestro slugfest programado regularmente!

Esto me parece aterrador, porque parece implicar que la lista de archivos en .csproj está regresando.

Además, aparte, ¿soy la única persona en el planeta que aprecia esta característica? : Lengua_salida_atascada:

Esto me parece aterrador, porque parece implicar que la lista de archivos en .csproj está regresando.

Además, como comentario al margen, ¿creo que es la única persona en el planeta que aprecia esta característica? : Lengua_salida_atascada:

@ Mike-EEE Sí, creo que lo eres. :guiño:

El caso de uso principal de los archivos vinculados es el de apuntar a múltiples plataformas. Esa es una característica de project.json que realmente quiero mantener. No creo haber visto ningún comentario específico sobre esta capacidad, pero sería bueno si el equipo pudiera afirmar su intención de volver a crear esto en msbuild.

¡@shederman sabe cómo derribar!
😆

Lo intento. Sin embargo, espero no insultar a nadie. Intenté con todas mis fuerzas ir tras las discusiones.

Me irritan particularmente los insultos personales sarcásticos, así que cualquiera que discuta en mi contra, esa NO es la manera de callarme. 😉 Y hubo bastantes de esos.

Tengo curiosidad por los casos de uso para editar archivos csproj. Mi experiencia es que solo tuve que editar archivos csproj cuando nuget estropeó algo o se rompió una ruta de acceso. Para agregar nuevos pasos al proceso de compilación, siempre he usado un archivo build.proj de nivel superior que fue ejecutado por mi sistema CI. Nunca uso los archivos .sln en mi configuración de CI.

¿Es el propósito principal que las personas quieran editar archivos csproj para agregar los pasos BeforeBuild y AfterBuild que desean ejecutar cuando depuran en Visual Studio?

@ Mike-EEE Quizás; En su mayoría, recuerdo que era un verdadero dolor de cabeza cuando se trataba de proyectos con una gran cantidad de archivos (por ejemplo, Expression Blend, Visual Studio XAML Designer, etc.) hasta el punto de que lo cambiamos por la selección de comodines, lo que hace VS no sé cómo trabajar correctamente, lo que significa que cada vez que agrego un archivo tengo que volver a cargar el proyecto (o encontrar el error "este archivo ya está agregado" en la compilación)

¿Qué es lo que realmente le gusta de esta "función" (no compartir archivos entre proyectos, eso es obviamente útil, pero VS solo funciona correctamente cuando cada archivo se enumera individualmente)?

¿Qué es lo que realmente le gusta de esta "función" (no compartir archivos entre proyectos, eso es obviamente útil, pero VS solo funciona correctamente cuando cada archivo se enumera individualmente)?

Es cierto que esto es un mal hábito, pero me gusta poder eliminar archivos de mi proyecto cuando estoy refactorizando. O incluso desde una perspectiva histórica. Si sé que estoy trabajando en algo que podría querer más adelante, lo guardo en el disco pero lo elimino del proyecto. Por supuesto, esto contamina el control de repositorio / fuente (ver: mal hábito), pero disfruto ese tipo de control. Porque ahora, cuando quiero ese archivo, no tengo que andar con el historial de un repositorio (¿cómo encontrar este historial de un archivo eliminado ??? ¡demasiado trabajo!), Simplemente "muestro todos los archivos". y volver a agregarlo a mi solución. Historia instantánea. :sonrisa:

Tengo curiosidad por los casos de uso para editar archivos csproj

Para .csproj (cada uno de estos lo he hecho, y para la mayoría, varias veces)

• Si necesita hacer referencia a tipos de UWP desde una aplicación de escritorio
• Si necesita arreglar VS rompiendo cosas con NuGet (especialmente al agregar archivos a.targets e incluye .proj / .props)
• Si necesita cambiar el diseño de la salida generada
• Si está refactorizando proyectos y cambiando el nombre de ensamblajes
• Si está haciendo una gran refactorización que afecta a muchos archivos
• Si tuvo un conflicto de fusión porque varias personas están trabajando en el mismo proyecto y no está utilizando comodines
• Si necesita comprender por qué la compilación no funciona de repente (Edición: debería haber especificado, esto es más un "por qué necesito que sea legible y 'autónomo'")
• Si necesita depurar conflictos de versiones de ensamblado debido a dependencias molestas
• Si está intentando agregar un archivo "vinculado" (compartido)

Para project.json

• Crear el archivo desde cero a mano (muy importante)
• Agregar / quitar paquetes NuGet
• Cambiar el marco de destino
• Cambiar la versión del paquete de salida

@shederman me doy cuenta de que estás frustrado, pero cuando respondes con

¿En serio? ¿La gente todavía hace eso? Quiero decir, solía hacerlo para AssemblyInfo.cs, y en la Edad Media

Estás marcando un tono. Está bien hacerlo en una conversación cara a cara, pero en este tipo de entorno, tiende a abrir la puerta a una amplia gama de comentarios basados ​​en emociones que tienden a polarizar la conversación y dificultan la concentración en los puntos importantes. Sé que es difícil mantener la emoción fuera de estas discusiones (mi lengua está llena de marcas de mordiscos ;-)) pero realmente tenemos que intentarlo para que la discusión sea útil.

@ Mike-EEE ¿No podría lograr lo mismo (sin enumerar todos los archivos) usando el atributo / patrón Exclude ? Para que conste, a menudo hago lo mismo, es muy útil cuando solo desea eliminar algo rápidamente sin tener que hacer un ciclo de confirmación / retroceso.

Para que conste, en realidad me gusta la propuesta de @ Mike-EEE de usar Roslyn y hacer que el archivo del proyecto sea un AST serializado. Pero solo si podemos lograr que sea igualmente fácil trabajar usando solo el bloc de notas. (Sí, me refiero al bloc de notas, no al bloc de notas ++ o cualquier otra cosa más avanzada: esa es la "prueba de humo" para la usabilidad de un formato de archivo editable por humanos)

@CodingGorilla Estoy abierto a ello. Preferiría que las herramientas me ayuden con esto (defina el patrón por mí en lugar de averiguar cómo hacerlo; si siento que estoy trabajando con DOS nuevamente, ¡TODOS PIERDEN!). Debería poder tener exactamente la misma experiencia que tengo ahora.

Básicamente, mirar un modelo de "exclusión voluntaria" en lugar de "suscripción voluntaria".

Para aquellos que quieran editar archivos de proyecto sin descargar ... https://twitter.com/migueldeicaza/status/730978470734401536

Para aquellos que quieran editar archivos de proyecto sin descargar ...

@darrelmiller, ¿qué estoy viendo aquí ... sugiriendo usar Xamarin Studio en su lugar? ¡Sí, esa descarga / carga de negocios / flujo de trabajo / experiencia es lo PEOR! Ha existido desde 2003, je.

Apoyo la idea de que el archivo eventual debería ser fácilmente editable y legible con un editor de texto estándar (es decir, un bloc de notas), sea cual sea el formato.

También creo que una mejor herramienta eliminaría muchos de los puntos débiles detrás del csproj actual. VS no es el mejor ejemplo y creo que la experiencia que VS te brinda es lo que mucha gente odia del sistema de proyectos MSBuild.

@ Mike-EEE La respuesta al comentario de Miguel fue de David Kean, quien trabaja en el nuevo sistema de proyectos. El equipo sabe que VS también debe poder hacer esto.

@ Mike-EEE Creo que lo mío es que puedo lidiar con lo que se me ocurra. El sistema de proyectos de MSBuild es lo suficientemente robusto como para hacer casi cualquier cosa (a menos que, como dice @shederman , simplemente _no_ puede ser XML). Creo que algunas personas simplemente están señalando el "debe ser mi camino o es un FALLO", y como alguien más dijo (lo siento, olvidé quién, este hilo es YUUUUUUGE!) "Trato de mantener la mente abierta ..." y simplemente adáptese.

Además, es posible que aprenda algo nuevo, y eso siempre es bueno. : sonriendo:

@neoKushan Solía ​​escribir scripts de msbuild desde cero, de hecho es mucho más poderoso que el msbuild con sabor. Pero tampoco fue genial, y estoy bastante feliz de no estar haciendo más. Creo que podríamos encontrar algo mucho mejor que esto.

@CodingGorilla En realidad, mi principal problema es MSBuild. XML es un problema, pero no tan malo como MSBuild.

Me ofrecí a hacer el trabajo yo mismo para mantener el soporte de project.json funcionando junto con xproj. El que más se preocupa, hace el trabajo, ¿no?

Y este es, de hecho, el quid. ¿Me permitirá el equipo hacer esta contribución? Y si no, ¿Pórque no? Después de todo, es OSS, ¿no?

Entonces, si te gusta MSBuild y quieres su potencia, usas xproj.

Y si le gustan las herramientas que se crearon para el núcleo de ASP.NET, continúe usándolas.

Usan el mismo compilador subyacente.

Y ni siquiera debería ser tanto trabajo en cualquier caso. Todo lo que tengo que hacer es refactorizar el código que están desaprobando en otro comando.

Idealmente, me gustaría poder usar "dotnet build" y mirar el directorio y decidir cuál usar en función de los archivos que hay allí. Pero una marca de opción en la compilación o incluso un nuevo comando estaría bien.

@sandorfr Estoy de acuerdo en escribir archivos MSBuild completos que definan su proceso de compilación _entire_ es nada menos que un dolor colosal, pero si no me equivoco, eso no es de lo que realmente estamos hablando aquí, estamos hablando de _sólo_ el proyecto estructura.

Dicho de otra manera, MSBuild es un sistema enorme y poderoso y con eso viene mucha complejidad, pero solo si lo usa. VS, por defecto, arrojó un montón de basura que no necesitaba y, al mirar el xproj, está claro que MSBuild tampoco lo necesitaba. Si el equipo de donet se enfoca en minimizar lo que se requiere en el csproj, debería ser relativamente mínimo y limpio para la mayoría de las personas. Los únicos que deberían sufrir un "infierno de fusión" serán los que quieran esa funcionalidad extra (que sospecho que son los que están impulsando este cambio, en su cabeza).

Todavía no hay nada que le impida usar el sistema de compilación de su elección, ya sea CAKE o TFS Team Services o lo que sea.

Nuevamente, esto estipula que el equipo lo haga "bien".

VS no es el mejor ejemplo y creo que la experiencia que VS te brinda es lo que mucha gente odia del sistema de proyectos MSBuild.

@neoKushan Eso es lo que siento por TFS Build y Xaml. Xaml es ridículamente asombroso (y aún me ENCANTARÍA verlo usado como un posible formato para "scripts" de MSBuild), pero su uso en TFS Build le ha dado un mal nombre.

No creo que sea productivo usar este problema de github como una ventana de chat. Quería mantener las notificaciones por correo electrónico para este hilo en caso de que alguien de MS respondiera, pero la cantidad de correos electrónicos se volvió demasiado molesta.

El sistema de proyectos de MSBuild es lo suficientemente robusto para hacer casi cualquier cosa

Eso es parte del problema y lo que hace que sea tan difícil entender lo que sucede en un archivo csproj al leerlo, lo que lo convierte en una mala elección para un formato de archivo de proyecto (que no debe confundirse con un formato de archivo de definición de compilación).

(Editar: agregado)

Todavía no hay nada que le impida usar el sistema de compilación de su elección, ya sea CAKE o TFS Team Services o lo que sea.

Desafortunadamente, significa que estamos atrapados tratando de calzar nuestro sistema de compilación en MSBuild si queremos que VS pueda hablar con él (y que funcione correctamente cuando hay código tanto administrado como nativo y queremos depurar). Esta es la razón por la que, en realidad, creo que es una _característica_ dividir el archivo de proyecto del archivo de compilación.

Jaja, sí @ cwe1ss (¡hablando de mejoras en las herramientas!) Estaba pensando que GitHub es terrible para cuando las cosas estallan en una conversación. Tenemos como 3 hilos aquí. Y acabo de empezar otro. :decepcionado:

¿Puedo sugerir que todos saltemos a la próxima reunión comunitaria el miércoles? Sospecho que se hablará principalmente sobre el lanzamiento de RC2 uno o dos días antes (¡uno puede esperar!), Pero nos dará la oportunidad de hacerles ping con las preguntas necesarias y tener una buena discusión franca con una audiencia en vivo. que realmente puede dar respuestas.

¿Puedo sugerir que todos saltemos a la próxima reunión comunitaria el miércoles?

Solo si @shederman representa. Quiero verlo aplastar a los desarrolladores y sus ideas en tiempo real. ¡Como un evento PPV de la WWE!

Creo que la ventaja de project.json sobre [projectName] .csproj no se trata del formato. Se trata de no tener que ser compatible con todas las versiones anteriores. Eso permitió que fuera bastante simple. Suponiendo que Damian Edward y su equipo puedan cumplir con todos sus objetivos especificados, realmente no me importa XML versus JSON versus YML versus ... Lo que es importante para mí es la simplicidad y no tener que ver cosas que están ahí para Windows cuando estoy en Linux .

@glennsills No creo que haya mucho de nada en un archivo de proyecto de MSBuild que sea específico de _windows_, es más que es específico de MS Build en sí mismo u otros tipos de proyectos que simplemente no te importan. Realmente no es necesario tener un montón de elementos vacíos solo para mantener feliz a MSBuild. Espero que el equipo esté planeando eliminar tanto como sea posible, pero ya veremos.

@ Mike-EEE Solo si @shederman representa. Quiero verlo aplastar a los desarrolladores y sus ideas en tiempo real. ¡Como un evento PPV de la WWE!

Trataré de hacerlo. Sin embargo, te advierto que hablo más lento de lo que escribo, así que no te hagas ilusiones 😄

Entonces, a riesgo de abrir una lata de gusanos, dado https://github.com/dotnet/roslyn-project-system/issues/40, ¿cómo se sentirían las personas acerca de un archivo csproj genuinamente reducido que solo contuviera (por defecto ) ¿Lo esencial para el proyecto?

(Por favor, no convierta esto en una diatriba de "¡Odio XML!").

¿Qué tal un "Odio la diatriba de MSBuild"?

@shederman

¿Qué pasa si hacemos que MSBuild acepte archivos JSON? : riendo: (no pude resistir)

@shederman , es difícil tomarse cualquier tipo de diatriba en serio y preferiría que Microsoft se tomara esta _discusión_ en serio.

De la forma en que esto va en 5 años, estarás programando Swift, Java (!!), Node.JS o Elixir. ;)

Hay dos tecnologías de mierda en estos días en proyectos .NET / Soluciones / lo que sea. Archivos Nuget y .csproj. Si trabajas en un equipo de 5+ usando Git (y por ejemplo, GitFlow) es una pesadilla total. La "mierda si se olvidó de incluir el archivo en .csproj" se está volviendo tediosa. Las herramientas deberían solucionar eso, las herramientas también deberían advertirme que tengo versiones de DLL en conflicto, las herramientas deberían ayudarme con la fusión.

Corta la mierda. Project.json parecía agradable al principio, pero luego sucedieron la política y los sentimientos.

MS Team debería llamarlo beta, no RC.
Parece que no puedo confiar ni siquiera en el lanzamiento de RTM, en caso de que sea posible que el equipo de MS decida enviar RTM2, lo que rompió todo de nuevo.
No soy pesimista, pero este movimiento en torno a .NET Core es muy extraño.

@neoKushan Intentaré ser lanzar una diatriba. Dicho esto, no creo que ninguna opción de MSBuild sea buena, y tampoco creo que XML sea una buena opción.

No estoy de acuerdo con los términos de la discusión en los que tengo que renunciar a los puestos que ocupo para poder entrar en la discusión. Sigo escuchando cómo aquellos de nosotros que estamos a favor de project.json debemos aceptar básicamente exactamente lo que MS ha decidido, tal vez con una modificación menor o dos.

No veo cómo sigue eso. Simplemente quiero el sistema de compilación que se prometió y con el que se comprometió. Si la EM no está dispuesta a mantenerla y continuarla, me ofrecí a hacerlo.

Entonces, ¿dónde está el problema? No le estoy pidiendo a MS que se retracte de sus planes, no les estoy pidiendo que agreguen trabajo. Solo les estoy pidiendo que me permitan cumplir las promesas que incumplieron unilateralmente.

Difícilmente una petición revolucionaria.

Mis 2 centavos:

Creo que hay dos tipos de personas que discuten este cambio:

desarrolladores que han estado usando VS y .NET para construir varios tipos de proyectos y tienen que apoyar esos proyectos durante mucho tiempo
desarrolladores que no tienen tanto equipaje y quieren un marco ASP.NET Core nuevo, limpio y elegante, multiplataforma
Personalmente, estoy en la primera categoría, así que quiero que el nuevo ASP.NET Core sea lo más compatible posible con otros tipos de proyectos VS, y pasar a la solución csproj / msbuild "antigua" es una victoria para mí (+ mi equipo y probablemente muchos otros desarrolladores). De esta forma la transición sería mucho más suave y clara. Tal vez la gente de la segunda categoría no esté de acuerdo conmigo (o simplemente no les importa).

El único problema importante que veo ahora es cómo se definen y se hace referencia a los paquetes NuGet. Es una molestia tener que mantener los archivos packages.config y csproj (como @JulianRooze ya mencionó en # 1433 (comentario)). Esto tiene que ser refactorizado. Idealmente, debería hacerse como @ cwe1ss sugirió en # 1433 (comentario)). Fue uno de los comentarios más constructivos en este tema por cierto ...

En cuanto a la guerra santa XML / JSON ... En mi humilde opinión, XML es mejor para la edición manual que JSON. XML admite comentarios y tiene más información de contexto cuando lo mira. JSON es mejor para los datos, no para los archivos de configuración. La combinación es igualmente buena y mala para ambos formatos, depende únicamente del contenido. Si las referencias del proyecto se separaran de los archivos csproj actuales, la fusión también sería mucho más fácil ...

También encajo en la categoría uno (desarrolladores que han estado desarrollando múltiples proyectos / tipos y necesitan apoyarlos durante mucho tiempo). Mi empleador tiene millones de líneas de código de proyectos en formato csproj y también tenemos productos más nuevos que se ejecutan en ASP.NET RC1 y RC2 dev branch. Advertencia justa, también hacemos un uso avanzado de MSBuild con ensamblados de tareas personalizados de MSBuild, etc.

La integración del mundo real entre los dos ha sido un desastre (por múltiples razones), especialmente considerando cosas como generar envolturas, volver a generar envolturas cuando las dependencias envueltas cambian, cómo se ve esto en el control de fuente (admitimos y usamos internamente tanto Git como TFVC ), cómo los proyectos se referencian entre sí en una solución en el momento del diseño en VS frente a cómo se incorporan en el momento de la compilación / implementación. El sistema nunca se sintió _correcto_. No tenía sentido que pudiera tener dos proyectos separados, cada uno con solo archivos .cs, pero estos dos tipos de proyectos no podían combinarse bien.

En ese sentido, entiendo totalmente por qué es importante admitir aplicaciones y códigos que se han escrito hasta este momento. No creo que sea el momento adecuado para introducir este tipo de cambio, con todos los demás cambios en marcha, parece que están sucediendo demasiadas cosas a la vez.

¿Quizás una posible solución futura es seguir el ejemplo de otras personas y pensar en los lanzamientos de LTS o algo similar? Esta es una conversación mucho más amplia, pero luego se podría introducir alguna característica como un reemplazo del sistema de proyecto y dar tiempo a la gente para asimilarla.

Otra posible solución es un sistema de compilación más conectable, pero esta es una solución a más largo plazo y no ayuda a la conversación actual. Básicamente, permite cualquiera / o / terceros.

Acerca de las dependencias del proyecto, ya tenemos toneladas de archivos packages.config flotando, portarlos a packages.json / nuget.json no es gran cosa. Tengo más problemas con las redirecciones de enlace de ensamblaje inconsistentes que con el formato de almacenamiento para las dependencias.

@shederman Has dado a conocer tu opinión sobre MSBuild, pero lo que no has dejado claro es tu _problema_ real con MSBuild. Esto es lo que me resulta tan frustrante, solo quiero saber los problemas reales que ha encontrado con MSBuild porque realmente siento que se pueden abordar.

De acuerdo, no te gusta XML, de acuerdo, el debate entre JSON y XML no es nada nuevo y nunca lo resolveremos aquí. Sin embargo, esa no puede ser la única razón por la que odias tanto a MSBuild. ¿Cuáles son los problemas reales que ha encontrado?

La razón por la que pregunto, y la razón por la que sigo preguntando, es que estos son los problemas exactos que Microsoft quiere solucionar y, a menos que dejemos en claro cuáles son los problemas, no se solucionarán. Muchas de las cosas que odiamos de MSBuild ya se están arreglando que conocemos:

1. Listado de todos los archivos del proyecto que se eliminan / arreglan (en realidad, un problema de VS)
2. Fusionar el infierno - Corregido por 1. en la mayoría de los casos
3. Complejidad / verbosidad innecesaria: es de esperar que se resuelva en https://github.com/dotnet/roslyn-project-system/issues/40
4. No se puede editar fácilmente a mano: nuevamente, se corrigió en 1. y 3.

¿Lo que queda? Analicemos realmente los problemas con MSBuild y veamos si hay una solución que no implique bifurcar todo o abandonar decenas de miles de proyectos intrincados y críticos para el negocio. Esa es la discusión que _quiero_ tener.

Mi 2 centavo en esto:
¿Por qué diablos este tipo de cambio tiene lugar ahora mismo? Según la hoja de ruta, solo queda 1 mes hasta el lanzamiento final.
Cuando vi esto por primera vez, pensé que era una broma. Pero lamentablemente no lo es.
Esta es una gran bofetada en la cara de la comunidad. Tal decisión debe tener largos hilos de conversación ANTES de que se adopte, no después.

@laskoviymishka (y algunos otros) como lo ha señalado @neoKushan aquí, este cambio _no_ está sucediendo ahora, este será un cambio posterior a RTM (incluso RTM estará en fases). Así que toda la charla de "por qué el cambio de última hora" es un argumento un poco falaz, hay _ tiempo para ver cómo evolucionarán las cosas.

@laskoviymishka El cambio no se está produciendo antes de RTM.

RTM seguirá usando project.json como se usa hoy (creo que el esquema está cambiando para RC2 pero eso estaba sucediendo independientemente). El cambio a un "nuevo" csproj está programado para después de RTM y se hará gradualmente. Nada cambia en RTM (excepto que se cambia el nombre de xproj).

@CodingGorilla esto es RC2, que se transferirá a la versión 1.0 en un mes. En el mundo real, esto significa que dejas de desarrollar todo y te concentras en la estabilización. Este cambio realmente no estabiliza nada.

@neoKushan si sucederá después de RTM, ¿por qué no asc community al respecto? Inicie un hilo de discusión en github. Empiece a señalar argumentos, etc. ¿Por qué debería forzarse sin conversar con los desarrolladores?

En mi humilde opinión, este movimiento de project.json a project.csproj debe discutirse antes de ser adoptado. Ahora mismo no es una buena decisión, al menos para mí.

@laskoviymishka De la comunidad notas de pie : (énfasis agregado)

En RC2 / Preview 1, no habrá cambios . En RTM / Preview 2, _el único cambio que verá si Visual Studio cambiará el nombre de los archivos xproj a csproj_. A partir de ese momento, project.json vivirá junto a csproj. Luego, el equipo comenzará a migrar características de project.json al archivo csproj. Es posible que el archivo project.json permanezca y contenga todas las referencias del paquete para NuGet y se le cambie el nombre a nuget.json. El equipo ya ha probado algunos trabajos que muestran que no necesitará enumerar todos los archivos en su archivo de proyecto, uno de los beneficios clave del modelo project.json.

Entonces, esto es principalmente un cambio de herramientas, y en el muy corto plazo (es decir, RTM +) el archivo project.json seguirá ahí y seguirá funcionando igual que ahora. La buena noticia sobre esto, creo, es que todavía hay tiempo para que la comunidad tenga un impacto en esto, si podemos mantener las cosas de manera civilizada y constructiva.

@laskoviymishka Bueno, realmente no quiero hablar en nombre de Microsoft, no sé cuál es su plan final, pero tampoco creo que ellos lo sepan realmente. Mucha gente dice que se les quitó la alfombra y que Microsoft debería habernos consultado antes de decidir esto, pero, en realidad, nada ha cambiado todavía y nada cambiará durante meses; además, cuando se produzca el cambio, será un cambio gradual y, con suerte, uno que el herramental hará más o menos por usted.

Microsoft, o al menos el equipo de asp.net, ha solicitado comentarios sobre esto y no hay duda de que están leyendo estos hilos, pero quizás lo que nos falta es un boletín o publicación definitiva de Microsoft que diga "Si quieres discutirlo, hazlo _aquí_ ". Sin embargo, creo que la transición es mucho antes de lo que la gente piensa. Hasta ahora, lo único que saben con certeza es cambiar el nombre de xproj a csproj.

Personalmente, creo que, aunque es un cambio un poco horrible, entiendo sus razones para hacerlo. No tengo una mejor respuesta, así que mi opinión es que si tenemos que lidiar con proyectos de estilo csproj, entonces también podemos aprovechar este período para presentar la mejor _kind_ de csproj que podamos. No será project.json, pero si podemos obtener lo mejor de ambos mundos, a la larga, todos estaremos mejor. No todo el mundo está de acuerdo y está bien.

@neoKushan, este es un buen punto, espero que MS lo vea. Será muy agradable ver los comentarios del equipo central.

@CodingGorilla bueno todavía hay cambios en la versión final, que se está rompiendo. El principal problema de este cambio es que el equipo central tiene que dedicar mucho tiempo a nada, lo más probable es que sea un problema de los gerentes. Dediquemos muchas horas de desarrollo solo para cambiar una cosa en funcionamiento a otra que probablemente funcione. Sin ninguna buena razón.

@neoKushan

Analicemos realmente los problemas con MSBuild

Me está costando encontrar suficiente información para formarme una opinión. Hubo muchos cambios que _ parecen_ ser habilitados por project.json y la eliminación de archivos .csproj. No quiero que estas mejoras desaparezcan, pero no sé cómo el cambio a un msbuild "nuevo y mejorado" cambiará mi flujo de trabajo:

• Actualmente, usamos gulp para cada tarea de compilación. ¿Eso cambia? Mi gulpfile simplemente se ejecuta en dnu o dotnet-cli para convertir una colección de archivos .cs en un ensamblado. Puedo quedarme con eso, ¿verdad?
• ¿VS continuará apoyando el explorador de tareas y los activadores de afterbuild / prebuild / etc para mis tareas de gulp, de modo que los usuarios de VS puedan ejecutar F5? ¿O tengo que hacer que msbuild inicie gulp, lo que significa que todas mis tareas de gulp necesitan tareas de envoltura de msbuild definidas? (Ay)
• ¿Se encuentra msbuild en una instalación separada? ¿Será versionado por separado de dotnet cli o del tiempo de ejecución? ¿Cómo cambia esto el mínimo que debe estar disponible en mi servidor de compilación de CI? ¿Mínimo para instalar en un entorno de desarrollo?
• Si estoy usando un editor de texto para agregar dependencias nuget o archivos .cs, ¿qué pasos adicionales debo agregar ahora, si corresponde?
• Cuando estoy revisando un conjunto de cambios donde un usuario de VS agregó una dependencia nuget y un archivo .cs, ¿los cambios de csproj serán simples y legibles por humanos? (En comparación, con .net 4.6 y VS2015, mi opinión es que los cambios en csproj _no_ son fácilmente legibles por humanos).

Me gustaría ver a las personas que están haciendo este cambio buscar los escenarios que necesitan considerar (¡como el mío!), Y discutir sobre estos para que sucedan. Espero que el tipo de cosas "hey, estamos moviendo su queso sin ninguna discusión" no se convierta en el SOP de .net core.

que las herramientas te servirán más o menos

Y ese es el quid principal. Cuantas menos herramientas se requieran, mejor. Actualmente puedo usar un editor de texto y la línea de comandos sin sentir que estoy nadando contra la corriente. Espero que eso no cambie. En .net46 land, tengo que editar un archivo xml gigante y detallado si no quiero usar VS, y mezclar usuarios de VS con usuarios que no son de VS en el mismo proyecto es una pesadilla.

"Bienvenido a RTM. Este es un recordatorio de que el archivo de su proyecto cambiará en algún momento en un futuro muy cercano. Ya lo hemos decidido. Razones, pero sobre todo porque nos gustan los ángulos más que los curlies, oh, y las herramientas de construcción, sí, construyen herramientas. No hemos determinado el esquema final (pero estará basado en xml, ver arriba), y el nombre del archivo definitivamente terminará con .csproj para generar la máxima confusión en cualquier herramienta heredada. Agile. (ps si es un proveedor de herramientas:: o) "

@Oceanswave hermoso ejemplo de cómo no debe administrar el desarrollo de su software

@neoKushan

pero lo que no ha dejado claro es su problema real con MSBuild

¿Quizás debería leer mi respuesta anterior a esta misma pregunta exacta de usted? https://github.com/aspnet/Home/issues/1433#issuecomment -218993559

He perdido cientos de horas a lo largo de los años arreglando, desarrollando y depurando archivos de MSBuild. He hecho Team Builds, he realizado grandes builds y pipelines. He pasado horas y horas estudiando minuciosamente registros detallados tratando de averiguar por qué diablos está ocurriendo una situación extraña. He pagado mis cuotas a lo largo de los años por esta tecnología y, personalmente, no quiero tener nada que ver con ella. project.json fue un soplo de aire fresco. Después de años de sufrimiento con MSBuild, finalmente tuvimos la impresión de que la EM lo tenía, que se necesitaba un cambio y que se estaba aplicando.

Y fue glorioso. Compilaciones simples, ediciones simples, salidas rápidas y fáciles de entender. Se borró el recuerdo de esas horas maldiciendo los scripts de MSBuild. Parecía que finalmente nos estábamos separando del cadáver del pasado. Pero no, ahora estamos encadenados al cadáver que tanto odiamos, a pesar de la promesa de que esto no sucedería.

Sin discusión, sin revisión, sin ningún tipo de compromiso.

El hecho de que ni siquiera seas consciente de cuánto se odia a MSBuild en algunos sectores simplemente demuestra que no tomaste ninguna diligencia en esta decisión.

No creo que MSBuild tenga limitaciones funcionales significativas como sistema de compilación. Es increíblemente poderoso y, en cierto sentido, esa es su principal debilidad. Es complicado porque tiene que manejar muchos escenarios. Para un escenario simple de "restaurar, construir, probar, empaquetar", realmente es una exageración enorme.

En mis equipos, estamos tratando con desarrolladores de C #. Están bajo presión, plazos ajustados, mucho estrés. No quieren nada que se interponga en su camino o los retrase.

MSBuild es una forma diferente de pensar, un cambio de contexto importante de la codificación imperativa. Los desarrolladores simplemente lo odian. Lo encuentran obtuso y contrario a la intuición. Lo evitan. El único MSBuild que se crea en cualquiera de los equipos que superviso en estos días es la herramienta creada.

No he conocido a un solo desarrollador de C # en los últimos 5 años o más que esté emocionado o disfrute trabajar con MSBuild. Mira algunos de los comentarios de los últimos días en Github. De ninguna manera estoy solo en mi disgusto por MSBuild. MSBuild se ha percibido como una piedra de molino en el cuello de los desarrolladores de .NET durante una década. ¿Es injusta gran parte de esa percepción? Sí, muy probablemente.

¿Y qué? Desde mi perspectiva como Jefe de Ingeniería de Software, necesito herramientas que produzcan los resultados que deseo. No obtengo esos resultados con MSBuild. Obtengo esos resultados de project.json + gulp.js + powershell.

_¿Puede MSBuild conseguirme esos resultados? Claro que puede, pero solo si los desarrolladores hacen el trabajo en MSBuild para obtener esos resultados. Y simplemente no lo hacen. Cuando los forzamos , lo hacen y luego no lo mantienen.

No puedo confiar en una herramienta que los desarrolladores odian. Esa es la simple realidad. Y teniendo en cuenta lo mucho que me ha gustado no usarlo, no puedo culparlos.

Analicemos realmente los problemas con MSBuild y veamos si hay una solución que no implique bifurcar todo o abandonar decenas de miles de proyectos intrincados y críticos para el negocio.

Bien, entonces, ¿qué se puede hacer?

Hace unos 5 años, si se hubieran introducido algunos de los cambios que se están discutiendo ahora, creo que la percepción sería mejor. Pero no fue así y ahora tiene una importante participación negativa entre una gran cantidad de desarrolladores. Según recuerdo, algunos de estos mismos problemas se plantearon con MSBuild en ese entonces y se rechazaron. Así como se plantean y rechazan cuestiones de actualidad.

No sé cómo puede recuperar eso, realmente no lo sé. Creo que tendría que haber algunas rupturas limpias importantes. ¿Cómo los haces sin romper lo que hay? Es muy poco, es demasiado tarde. Así que no veo un camino a seguir con MSBuild, ni para mí, ni para los desarrolladores que trabajan para mí, ni con mis socios, ni con los equipos que trabajan para ellos, ni con los clientes a los que consultamos. Ninguna de esas audiencias quiere usar MSBuild, lo usan en las herramientas porque tienen que hacerlo y lo juran repetidamente. Es cierto que normalmente en el momento de la fusión.

Entonces, ¿ahora quieres mejorar las fusiones? 10 años después. ¿Después de que la herramienta es una palabrota en muchos sectores?

Básicamente, estás usando una herramienta diseñada para Build Masters a finales de los 90 que en realidad está siendo utilizada por los desarrolladores después de 2010. Una herramienta que usa la inferencia para su lógica está siendo utilizada por desarrolladores que están acostumbrados al trabajo imperativo y herramientas imperativas. Una herramienta que utiliza una forma muy flexible, pero no obvia, de establecer propiedades que utilizan los desarrolladores que piensan que los conjuntos de propiedades son un operador de asignación simple y no entienden por qué querrías hacer un PropertyGroup y no No me importa averiguarlo.

Esa es la discusión que quiero tener.

Claro, lo entiendo. Sin embargo, la discusión que quiero tener es diferente, es "danos lo que nos prometiste, o déjanos dárselo a nosotros mismos, porque no nos gusta tu vieja idea nueva y nos gusta lo que nos prometieron".

¿Puedo compartir algo triste? De mis socios comerciales, que tienen una experiencia similar a la mía (más en realidad), yo era el más pro-MSBuild en su día. De hecho lo _usé_. Lo aprendí. Construí grandes oleoductos. Pero eso fue hace más de 5 años, y desde entonces ha pasado mucha agua por debajo del puente.

Hombre, me encuentro asintiendo con la cabeza profusamente mientras leo los comentarios y la historia de

Piense: Extensiones de Visual Studio (.vsix). Nadie quiere tocarlos por lo heredados / antiguos / diferentes que son en comparación con todo lo demás que existe en estos días. Bueno, tienes ALGUNOS desarrolladores que quieren hacerlo, porque han pagado su cuota para aprender su sistema arcano, al igual que MSBuild.

Yo también soy probablemente el más experimentado entre todos los que conozco profesionalmente que alguna vez haya tratado con MSBuild. La mayoría de los desarrolladores no quieren tomarse la cantidad de tiempo para aprenderlo (porque definitivamente tú lo haces). Es casi como si fuera su propio idioma.

Si fuera "más parecido a .NET" (y tuviera una mejor integración con VS), creo que todos estaríamos de acuerdo en que sería un mejor producto para trabajar y una propuesta atractiva a considerar.

@ Mike-EEE & @shederman Para Mike, es antiguo, arcaico y "diferente a cualquier otra cosa (.NET) con los que los desarrolladores tienen que trabajar ...". Pero, ¿es irreparable? Han admitido que hay problemas con él que quieren solucionar, por lo que la pregunta es: ¿Se puede solucionar? Creo que conozco la respuesta de @shederman , incluso estoy mayormente de acuerdo con su razonamiento (estoy de acuerdo con el tema de que construir y proyectar sistemas es una extraña mezcla de preocupaciones).

Una vez más, no tengo un caballo en esta carrera, no me importa el camino que elijan tomar. Realmente me gusta recibir reacciones de aprobación y escucharme hablar (con un lado de interés intelectual real en la conversación: reír :)

Realmente me gusta recibir reacciones de aprobación y escucharme hablar (con un lado de interés intelectual real en la conversación: reír :)

¡Feliz de ayudar! :sonrisa:

Pero, ¿es irreparable? ¿Se puede arreglar?

Depende de a quién le preguntes, de verdad. Sacar a relucir problemas en su repositorio como sugiere @shederman ha sido difícil y desafiante (y sí, censuré mis palabras allí: stick_out_tongue :). Parece que están establecidos en sus caminos. Pero, como sabe por la naturaleza del software, todo es posible con suficiente tiempo y esfuerzo. :guiño:

@PhilipRieck ¡Estás haciendo muy buenas preguntas! Desafortunadamente, no tengo respuestas definitivas para todos ellos, pero veamos:

Actualmente, usamos gulp para cada tarea de compilación. ¿Eso cambia? Mi gulpfile simplemente se ejecuta en dnu o dotnet-cli para convertir una colección de archivos .cs en un ensamblado. Puedo quedarme con eso, ¿verdad?

No _pienso_ que esto va a cambiar, estoy 95% seguro de que de lo que estamos hablando aquí solo afecta la _definición_ del proyecto, no cómo se construye realmente el proyecto (al menos más allá de llamar a dotnet build). La CLI de dotnet puede llamar a MSbuild en algún momento, pero en ese momento es algo oculto.

¿Se encuentra msbuild en una instalación separada? ¿Será versionado por separado de dotnet cli o del tiempo de ejecución? ¿Cómo cambia esto el mínimo que debe estar disponible en mi servidor de compilación de CI? ¿Mínimo para instalar en un entorno de desarrollo?

No tengo una respuesta definitiva a esto, pero _imaginaría_ que MSBuild viene como parte de la CLI de dotnet como una instalación completamente separada, incluso si ya tiene MSBuild instalado (digamos con VS). Sin embargo, pura especulación de mi parte. Sé que un gran objetivo de todo este proyecto ".net en todas partes" es tener la mínima cantidad de alboroto para que la gente se desarrolle. Debería ser literalmente apt-get dotnet-cli (o lo que sea), dotnet new, dotnet build. Nunca debería tener que llamar a MSBuild para construir el proyecto, ese es el trabajo de dotnet-cli.

Si estoy usando un editor de texto para agregar dependencias nuget o archivos .cs, ¿qué pasos adicionales debo agregar ahora, si corresponde?

Para los archivos .cs, definitivamente nada más, al igual que hoy: lo único en lo que han sido muy claros es que los días de especificar cada archivo .cs en su proyecto han quedado atrás (aunque presumiblemente aún puede hacerlo si lo desea , mirándote @ Mike-EEE). En cuanto a las dependencias, ciertamente a corto plazo (el corto plazo son meses), permanecerán en project.json y funcionarán exactamente como antes. Existe la posibilidad de que project.json se convierta en nuget.json y, por lo tanto, aparte de un cambio de nombre, nada más cambia, pero hay otras posibilidades para esto y esta parece ser una de las cosas principales de las que Microsoft no está seguro: deje que su voz ser escuchado sobre sus preferencias para esto.
(Mi preferencia personal es poder hacer algo como.nuget.json pero solo soy yo escupiendo).

Cuando estoy revisando un conjunto de cambios donde un usuario de VS agregó una dependencia nuget y un archivo .cs, ¿los cambios de csproj serán simples y legibles por humanos? (En comparación, con .net 4.6 y VS2015, mi opinión es que los cambios en csproj no son fácilmente legibles por humanos).

Para el archivo .cs, csproj no debería cambiar en absoluto. Para dependencias nuget, buena pregunta, de nuevo, esto está algo en el aire. Realmente no debería hacer que csproj cambie, pero el gran factor decisivo en este momento es si nuget debería vivir en nuget.json o si csproj debería tener esas cosas, y si están separados, qué tan difícil será acorralar ¿los dos?

Y ese es el quid principal. Cuanto menos herramientas se requieran, mejor. Actualmente puedo usar un editor de texto y la línea de comandos sin sentir que estoy nadando contra la corriente. Espero que eso no cambie. En .net46 land, tengo que editar un archivo xml gigante y detallado si no quiero usar VS, y mezclar usuarios de VS con usuarios que no son de VS en el mismo proyecto es una pesadilla.

Estoy completamente de acuerdo con esto, pero Microsoft ha invertido demasiado en sus esfuerzos multiplataforma para convertirlo de repente en una pesadilla. Al "herramientas", sospecho que dependerá de la CLI de .net en lugar de VS o algo por el estilo. No olvide que el "Fin del juego" definitivo para .net core es ser una plataforma muy ágil y de movimiento muy rápido, pero que no le obligue a perder tiempo actualizándose cada dos semanas. Estoy _ bastante seguro_ de que si escribe una aplicación dotnet 1.0 en junio, aún se construirá y ejecutará dentro de unos años, pero las versiones más nuevas serán un caso de ejecución de "actualización dotnet" o algo por el estilo cuando esté listo . Incluso cuando llega RTM, los proyectos RC2 seguirán compilando y ejecutando bits RC2 hasta que realmente ingrese y cambie el objetivo para que sea RTM (creo que en global.json o en algún lugar).

: riendo: Cuando leo hilos como estos, me pregunto si Microsoft tiene momentos de arrepentimiento. Realmente respeto y siento por los chicos que han hecho y están haciendo todo lo posible para darle la vuelta a Microsoft, con el objetivo de crear un refugio transparente, de código abierto y con mentalidad comunitaria para los desarrolladores. A los chicos detrás de esta transformación les importa. Son los buenos. Tienen que estar entre la espada y la pared en este momento; los sentimientos menos que constructivos de la comunidad que flotan alrededor (mientras me entretienen) no están ayudando a su caso.

Me gustaría señalar que reemplazar un montón de funciones mágicas de creación de proyectos que existen actualmente en el IDE con una aplicación de línea de comandos que hace mucha manipulación mágica de csproj es una mala idea. Hacer que el archivo de definición del proyecto sea lo más simple posible es imprescindible. La mejor parte de project.json es que puedo leerlo y entenderlo.

@shederman Su problema con MSBuild es que en un sistema grande y complejo es grande y complejo ...

También trabajé con Team Builds y también lo odié absolutamente (haciendo ping a Mike-EEE porque ambos hemos hablado de lo horrible que es esta experiencia), lo entiendo , pero lo que estás describiendo es completamente diferente guión. MSbuild _ puede_ ser grande y complejo y, por defecto, VS _ lo hace_ grande y complejo, pero eso es lo que está cambiando .

El archivo csproj más nuevo debería ser muchísimo más pequeño, lo que significa que la "depuración" debería simplificarse enormemente. Sin (o poco) cruft. Todavía puede usar cualquier _build system_ que desee, diablos, puede llamar a un archivo .bat que solo llame a "dotnet build" en * .csproj y obtendrá la salida que desea, como hoy. Deje que dotnet cli se ocupe de MSbuild y ni siquiera debería tener que tocarlo.

@neoKushan no, gracias.

Quiero lo que me prometieron, no lápiz labial en lo que nos dijeron que nos íbamos a alejar.

Y si no quieres darnos lo prometido, déjanos dárnoslo a nosotros mismos. Ya está todo ahí. Debería ser solo un caso de mantener las refactorizaciones. Haré el trabajo, como he dicho antes.

Sospecho que la razón número 1 por la que no hay ganas de dejarlo es la comprensión de que este sería el comienzo de una migración masiva fuera de los proyectos de MSBuild. Lo siento, pero mantener una tecnología obsoleta en soporte vital no es uno de los objetivos de diseño de .NET Core. ¿Lo es?

El mayor problema con ms build es quién lo solucionará y cuánto tiempo lleva. En este momento, proyectos completos de la redPEA tienen más de 1000 problemas abiertos, algunos de ellos realmente críticos. Mira SignalR.
Queda un mes hasta el lanzamiento, y este error está muy cerca del estado final.

Y ahora dicen que la compilación de ms podría mejorarse. ¿Tiene MS recursos suficientes para gestionar toda esta mierda heredada? ¿La comunidad puede manejarlo? Realmente no creo en eso.

@shederman

Y si no quieres darnos lo prometido, déjanos dárnoslo a nosotros mismos.

No te impiden hacer NADA. Continúe y bifurque, nada lo detiene. Si está esperando el permiso de Microsoft, entonces ya lo tiene, lo obtuvo en el momento en que abrieron el código.

Ya está todo ahí. Debería ser solo un caso de mantener las refactorizaciones. Haré el trabajo, como he dicho antes.

¿Entonces hacerlo? Una vez más, nada te detiene.

Sospecho que la razón número 1 por la que no hay ganas de dejarlo es la comprensión de que este sería el comienzo de una migración masiva fuera de los proyectos de MSBuild.

¿Por qué les importaría siquiera? ¿Qué diferencia hay para Microsoft si usa MSbuild o algo más?

La verdadera razón número 1 es que la estructura del proyecto del núcleo de ASp.net solo es realmente buena para el núcleo de asp.net. Hay cientos de otros tipos de proyectos que simplemente no serían adecuados para project.json. No importa el hecho de que project.json tiene sus propios problemas, de los que aparentemente todos nos hemos olvidado: la falta de comentarios es lo que me molesta (y no, sugiriendo algún otro formato siempre que no sea así) XML no ayuda).

Lo siento, pero mantener una tecnología obsoleta en soporte vital no es uno de los objetivos de diseño de .NET Core. ¿Lo es?

No, pero ayudar a las personas a trasladar sus proyectos antiguos y existentes a .net core es un objetivo. Además, estamos hablando de la versión .net core de MSBuild, no de la versión de escritorio completa, hay una diferencia .

Tu único problema es que se atrevieron a llamarlo MSBuild. Si hubieran creado un nuevo estilo de proyecto que resultó ser XML pero que se llamaba "CoreBuild" o algo así, no lo sabrías y todo lo que tendrías que seguir es "¡Odio XML!".

estás esperando el permiso de Microsoft, entonces ya lo tienes

No es del todo cierto. No quiero bifurcarlo , quiero mantenerlo en el repositorio principal. Hay una diferencia. Por lo tanto, nadie tiene que descargar un SDK de .NET completamente nuevo. Lo quiero en las herramientas, y para eso, sí, necesito su consentimiento.

Tu único problema es que se atrevieron a llamarlo MSBuild

No, que quieren _usar_ MSBuild. Diferencia leve, pero importante. Cambie el nombre del nuevo sistema de compilación project.json y llámelo MSBuild y lo usaré felizmente.

no sería más sabio y todo lo que tendría que seguir es "¡Odio XML!"

Quizás 😄

De todos modos, dando vueltas en círculos.

Ir a la cama.

Yo digo que lo dejes para el standup. Nadie está convenciendo a nadie. Estoy bastante seguro de que entiendo el lado pro-MSBuild, pero no estoy de acuerdo con él. Y estoy bastante seguro de que el lado pro-MSBuild entiende el lado no-MSBuild, pero no estoy de acuerdo con él.

Todo lo que digo es que podemos tener ambos. Sin (o muy poco) esfuerzo adicional por parte del equipo de EM. Luego, deje que las opciones se hundan o se sumerjan en el resplandor del uso de producción real.

Por la pregunta de @neoKushan :

¿Lo que queda?

De hecho, quiero enmarcar mi respuesta, si se me permite, en torno a los "principios" que describí anteriormente con lo que creo que lo convierte en un archivo de proyecto bueno y utilizable:

• Debe ser editable / legible por humanos

Tomando la declaración de @neoKushan anterior en el sentido de que se abordará, supongo que alguien en MSFT dijo / escribió esto. Dicho esto, quiero ver una propuesta basada en MSBuild en la que esto se aborde primero, antes de "comprometerse" (como Comunidad / Marco) con MSBuild.

Supongo que deshacerse de Guid ProjectType es uno de los principales elementos a abordar.

Pero me atengo a mi apéndice anterior: es un requisito estricto (no negociable) que para proyectos simples (por ejemplo, ASP.Net Hello World en Angular), puedo crear la totalidad a mano, en el bloc de notas. Si necesito usar Yeoman / VS / similar, no hemos podido proponer un archivo de proyecto editable por humanos.

• Debería permitir comentarios

Ya trabajando, en MSBuild

• Debe ser declarativo

Cambiar el orden de primer nivel (hijos directos de) puede cambiar todo el significado del proyecto, a menudo de formas difíciles de depurar. En ninguna parte es esto más notable que si lleva las importaciones de .targets a la cima por accidente.

• Debe ser autónomo

Este es mi mayor problema con MSBuild. Leer un archivo, de forma estática, no le da suficiente información para saber realmente lo que está sucediendo allí. Desde archivos .targets que provienen de rutas especificadas por _variable de entorno_, y el hecho mismo de que las variables de entorno son compatibles con eventos, hasta condicionales e importaciones, juntos obtienen lo que es efectivamente un entorno Turing Complete, a costa de un nivel muy alto de complejidad. y poca capacidad de herramientas. Postulo que la pésima integración de VS de MSBuild es una consecuencia de la dificultad de construir herramientas alrededor de eso.

Esto es similar al problema de la legibilidad / editabilidad humana.

• Debe estar diseñado para reducir los conflictos de fusión / simplificar la fusión, si es posible

MSBuild técnicamente admite esto en forma de comodines. El soporte de VS para comodines es peor que abismal. Activamente hace que sea más difícil trabajar. Según lo anterior, estoy dispuesto a aceptar que esto se solucionará, pero debe ser un elemento de una _propuesta_ para _ migrar_ (y es una migración a, porque todos los mensajes hasta ahora han sido sobre project.json) a MSBuild -Archivos de proyecto basados ​​en.

• Debe ser completamente documentable (con el principio de autocontención que se aplica a la documentación).

Creo que MSBuild tiene documentación. Esa documentación, especialmente para VS _flavor_ de MSBuild, deja bastante que desear. A menudo me quedo perplejo por qué hay diferentes cosas en los grupos en los que están, y VS "ayudar" a moverlas no es muy útil.

Un ejemplo perfecto es el paquete Bond NuGet. ¿Cuántas personas saben que si no tiene una carpeta BondInclude en el disco (si se hace referencia a ella en el csproj), la compilación no generará misteriosamente ninguno de los tipos de Bond en el ensamblaje resultante? (Sin ningún error arrojado, tampoco). Luego, crear una carpeta vacía con ese nombre y volver a cargar el proyecto lo arregla.

(Sí, lo sé, voy a presentar un error)

• Debe ser independiente de la herramienta

Digamos que no quiero tener nada que ver con MSBuild (digamos porque me siento contrario, sin profundizar más); Solo quiero definir mi proyecto y extraer paquetes a través de nugget. ¿Por qué me veo obligado a utilizar este sistema de compilación en particular? ¿Sobre todo si lo único que quiero es definir un proyecto?

Un archivo de definición de compilación no es un formato de archivo de proyecto. Que VS haya logrado que funcione (algo) no es un buen motivo para seguir usándolo como tal. Quiero un archivo real que solo represente el proyecto en sí e información sobre el artefacto que genera (no instrucciones sobre cómo construirlo). En esto, incluso project.json falla porque nos permite definir "comandos". ¿Por qué existen esos? Simplemente defina cuál es el tipo de salida y dónde se puede encontrar.

Leí todo este hilo, y una cosa que me llamó la atención en esta discusión de project.json vs project.csproj es que solo uno de esos nombres de archivo tiene un lenguaje de programación completo incorporado. Prefiero hacer el desarrollo de ASP.NET en F #. ¿Es eso incluso posible en ASP.NET Core? En este punto no tengo la menor idea, pero tengo la sensación de que no. Ni siquiera estoy seguro de si la gente está usando csproj como abreviatura de csproj, fsproj, vbproj o si realmente quieren decir solo csproj .

Actualización: la gente de F # está trabajando en la compatibilidad con CoreCLR, pero aún no hay una ETA real. Mi punto es que cualquier sistema de proyecto que se decida ahora afectará a los lenguajes de programación que ni siquiera parecen estar en el radar de la gente en este momento. Por mucho que prefiera JSON sobre XML, si project.json me va a bloquear en C # (y el orden de los archivos en la compilación es de vital importancia en F #), entonces no estoy a favor.

Por ahora, parece que ha vuelto a FAKE y Paket para mí ...

Estoy trabajando con .NET desde el principio y nunca he tenido problemas notables con MSBuild. La razón principal de esto es que nunca lo he usado para otra cosa que no sea la compilación de la solución lista para usar.

Y eso es lo que no entiendo de esta aversión por MSBuild. Nadie obliga a nadie a usar MSBuild para otra cosa que no sea la compilación de soluciones. Y creo que poder compilar una solución es una característica bastante útil, que por cierto ni siquiera existe en "dotnet cli" todavía (tienes que recorrer manualmente los proyectos en este momento; corrígeme si me equivoco).

Su sistema de compilación real no necesita cambiar. Si está usando Nant, siga usando Nant. Si está usando psake, siga usando psake. Si está usando un script de PowerShell, continúe usándolo. Etc. Lo más probable es que solo la parte "dotnet build" deba reemplazarse con una llamada a MSBuild. (Tal vez ni siquiera eso sea necesario si dotnet compila llamadas en MSBuild)

Yo diría que esto hace que MSBuild sea un detalle de implementación bastante poco importante. Así lo he visto durante la última década y así lo seguiré viendo.

Pero, por supuesto, como ya dije al principio de este hilo, lo que definitivamente necesitamos son algunas de las _características_ de project.json y Visual Studio para tratar mejor el csproj, y no veo por qué no lo harían ser capaz de entregar eso.

@jtmueller No hay absolutamente ninguna razón técnica por la que no puedas usar F # (o VB.net si así lo deseas). No me sorprendería que parte del cambio a los archivos de proyecto de MSBuild sea para ayudar a facilitar eso. DNX nunca estuvo realmente contento con él, pero CoreCLR definitivamente es compatible con F #. No sé si podrá usar F # come RTM, pero definitivamente está en proceso.

@jtmueller project.json es prácticamente una definición de proyecto con manifiesto de dependencia, además de comandos personalizados. No hay nada ligado a un idioma específico en absoluto.

El sistema de compilación de mis sueños (para reemplazar MSBuild por completo) usaría Roslyn para descubrir las tareas y los objetivos, lo que le permitiría usar F # para definir su proceso de compilación (o C #, o VB.NET, cualquier cosa que Roslyn admita).

Por supuesto, nadie propone eso todavía. Pero volver a encerrarnos en MSBuild cerrará casi con seguridad esa puerta durante mucho tiempo.

Tuve un buen descanso, y aunque un poco sobre el desafío de lo que hay que hacer para "salvar" MSBuild. No creo que podamos o debamos convertir MSBuild en un sistema de compilación significativamente diferente. Es un sistema de compilación definido por XML, basado en inferencias, y eso funciona para muchos escenarios de personas, especialmente algunos de los escenarios más complejos.

Pero no todos tenemos Build Masters dedicados que puedan lidiar con MSBuild. No todos necesitamos el poder que aporta la complejidad de MSBuild. Algunos de los que lo hacen necesidad de que la complejidad no quieren utilizar MSBuild. En uno de mis equipos, por ejemplo, toda la lógica de compilación personalizada se realiza en los pasos previos y posteriores a la compilación, Exec esencialmente está transfiriendo a Powershell. No porque no se pueda hacer en MSBuild, puede, y en ese caso probablemente _debería_. Pero debido a que no quieren hacerlo en MSBuild.

El primer paso es definitivamente que necesitamos separar la definición del proyecto del sistema de compilación. Para mí eso tiene mucho sentido. Podemos discutir la división de dependencias fuera de la definición del proyecto, pero no creo que sea necesario.

El segundo paso es que necesitamos un sistema de compilación. Necesitamos manejar casos de uso muy simples, así como también casos muy complicados. Pero ninguna regla dice que un sistema de compilación deba manejar _ambos_. En mi opinión, lo que tiene más sentido es tener un sistema de construcción simple y liviano que básicamente solo construye la definición del proyecto. Lo hace restore , build , test y pack .

Creo que también deberíamos buscar una manera de que pueda funcionar _sin_ una definición de proyecto en absoluto, utilizando la estructura de directorios como definición. Obviamente, tal situación significaría que usaría el marco predeterminado y las dependencias predeterminadas. Quizás sea posible, quizás no. Pero podemos mirar cada elemento en la definición y preguntar "¿podemos inferir un valor predeterminado inteligente para esto"?

Pero aunque eso probablemente sea suficiente para el 80% de los casos de uso, no es suficiente para el otro 20%. Necesitan algo más. (advertencia: las opiniones sobre las proporciones de casos de uso pueden variar).

El tercer paso es que permitimos una forma muy simple de extensibilidad a ese sistema de compilación. Pero estamos hablando muy simple. Básicamente, puede ejecutar su compilación básica o puede ejecutar un sistema de compilación externo. Dicho sistema de compilación externo puede ser MSBuild, scripts o algún otro sistema de compilación.

Estoy contento de que el nuevo proceso de compilación deba poder destinarse a MSBuild, pero no creo que algo tan (en mi opinión) antiguo, cascarrabias e hinchado como MSBuild deba ser la base de todas las compilaciones en el futuro.

Con cosas como los marcos web, vemos a los equipos de MS iterando frenéticamente. Porque tienen competencia. Tienen que preocuparse de que Nancy les respire por el cuello, por ejemplo. Es _fácil_ cambiar a otra cosa. Y hace que MVC / WebAPI sea mejor para él.

Con MSBuild integrado en todas las herramientas de .NET, usar cualquier otra cosa se convierte en una molestia. ¿Dónde está la competencia? Y puede ver los efectos de eso en el tablero de MSBuild Github. Simplemente revise todas las propuestas cerradas. La única razón por la que están hablando de hacer estos cambios "reductores" ahora es porque quieren que la gente se mueva de project.json a MSBuild.

Si MSBuild se hubiera integrado en .NET Core desde el principio, creo que no veríamos nada del movimiento que estamos viendo ahora del equipo de MSBuild. Pero, ¿qué pasa una vez que estamos encerrados de nuevo? ¿Una vez que la competencia está básicamente excluida? ¿Qué va a pasar? Lo que siempre sucede en escenarios sin competencia y lo que ha sucedido durante años hasta ahora: solo las mejoras suficientes para detener las deserciones masivas, pero nada particularmente interesante.

La gente me preguntó cómo creo que podemos "salvar" MSBuild. Creo que abrirlo a la competencia real y la elección es la única forma. Aplicarlo por mandato a todos los desarrolladores, incluso a aquellos que no necesitan nada tan poderoso (sí, creo que es poderoso), solo generará aún más resentimiento contra él.

Esa no es una receta para el éxito de ningún marco.

Por favor, tengan en cuenta que todos queremos que .NET tenga éxito. Me encanta .NET, creo que C # es uno de los mejores lenguajes de programación que existen y he disfrutado de su lenta transición a Scala - The Good Parts ™ 😉.
No creo que comencemos de nuevo con .NET Core, y lo hagamos encadenándonos a una de (IMO) las peores partes del viejo estilo .NET. Sí, MSBuild, pero no, no encadenado.

Por supuesto, manténgalo, pero no al frente y al centro integrado en el núcleo del sistema.

El sistema de compilación de mis sueños (para reemplazar MSBuild por completo) usaría Roslyn para descubrir las tareas y los objetivos, lo que le permitiría usar F # para definir su proceso de compilación (o C #, o VB.NET, cualquier cosa que Roslyn admita).

YAAAAAAAAAAS !!! Hablando de eso ... ¿es este el lugar adecuado para tener esta conversación? También tenemos los repositorios de Roslyn y MSBuild y parece que también deberían participar. Supongo que lo estamos probando en el repositorio de MSBuild, pero son (como mencionas) muy rígidos e inflexibles. Creo que tener más gente aquí como el interés que ha suscitado este hilo podría contribuir en gran medida a la reforma.

El tercer paso es que permitimos una forma muy simple de extensibilidad a ese sistema de compilación.

¿Un sistema / modelo de construcción basado en el proveedor? ¡GENIO! Yo apruebo este mensaje.

Por cierto, si obtiene su deseo y tiene acceso a su propio sistema de compilación, sugiero que lo llamemos ... BERSERKER BUILD! El nombre de "Berzerker @shederman" ... mi nuevo apodo para ti. :sonrisa:

@ Mike-EEE No se emocionen demasiado. De ninguna manera estoy proponiendo algo tan drástico como todo eso, todavía.

Por ahora, creo que deberían ser los Pasos uno y dos, con soporte de MSBuild para el Paso tres.

Pero este tipo de posibilidad es hacia lo que pensé que nos estábamos moviendo cuando obtuvimos project.json, separando el proyecto de la compilación para que sea más fácil intercambiar proveedores de compilación. En mi opinión, devolver MSBuild a la raíz cierra estas posibilidades. O al menos hace que sea mucho menos probable que obtengan tracción.

En este momento, las compilaciones personalizadas no obtienen adopción porque el sistema raíz _es_ tan poderoso. Es una conversación difícil convencer a las personas de que desea utilizar un sistema de compilación que no sea de MS cuando el sistema de compilación de MS realmente puede hacer todo lo que se necesita (ignorando el dolor).

¿Es este el lugar adecuado para tener esta conversación?

No lo creo, no. Además, no creo que sepa que es el momento adecuado todavía. Necesitamos cerrar este problema antes de ver qué direcciones son posibles.

¡CONSTRUYE BERSERKER! El nombre de "Berzerker @shederman" ... mi nuevo apodo para ti. :sonrisa:

No estoy seguro de cómo sentirme al respecto 😉

No estoy tratando de ser un berserker. Simplemente no quiero moverme hacia atrás cuando _ estábamos_ moviéndonos hacia adelante.

Hola chicos, tal vez en lugar de reinventar la rueda ( nuget.json o como se llame) usemos la solución existente impulsada por la comunidad que está resolviendo la mayoría de los problemas de gestión de dependencias: Paket .

1. Tiene concepto de dependencias transitivas
2. Está bien integrado con MsBuild
3. Tiene un formato de archivo legible por humanos para definir dependencias.
4. Tiene muy buena ruta de migración desde packages.config
5. Y muchas otras características (pero aparentemente esas 4 son las cosas más importantes para todos, por lo que no mencionaré cosas como las dependencias de Git o una mejor estrategia de resolución de paquetes)

@ Krzysztof-Cieslak recuerde que la principal razón por la que Microsoft está impulsando las definiciones de proyectos de MSbuild es para ayudar a facilitar la migración de aquellos que han invertido mucho en MSBuild. En ese sentido, Paket no es mejor que project.json (o project.yaml o project.cs o lo que sea).

Habiendo dicho eso, todavía no veo ninguna razón por la que no pueda usar el sistema de compilación que desee. En última instancia, "dotnet build" no va a cambiar, independientemente del formato que tenga la definición de su proyecto, dotnet build seguirá generando su salida.

@neoKushan Sí, pero ¿la "compilación dotnet" requerirá un archivo MSBuild incluso si no estamos usando MSBuild? ¿Se compilará si no hay ningún archivo MSBuild? ¿O se destinará a MSBuild que luego se destinará a cualquier otro sistema de compilación que se utilice?

@shederman No hay duda de que "dotnet build" utilizará MSBuild en segundo plano para construir los proyectos, pero si realmente vemos algo de eso, está muy en el aire. Actualmente, hoy en día, necesita un project.json para construir correctamente sus proyectos, si no es para referencias, para otros datos importantes (como marcos de destino). Eventualmente, parte (o incluso todo) de eso se migrará a un archivo csproj, por lo que se supone que necesitará ese .csproj para que funcione la compilación de dotnet, sin importar lo que finalmente use en segundo plano. Sin embargo, aún está por verse cuánto impacto tiene esto en ti.

Como dije, siempre que se me permita hacer el trabajo de mantener la construcción liviana en su lugar, que no requiere ningún MSBuild, estoy feliz. Ustedes pueden construir su canalización autorreferencial de "MSBuild en todas partes" por cualquier callejón sin salida que quieran.

Pero si eso va a funcionar, entonces csproj deberá incluir project.json como sugirió RichiCoder.

De esa forma, la "compilación del núcleo" y "MSBuild" pueden funcionar en paralelo, o la compilación del núcleo puede funcionar sin MSBuild. Y, obviamente, si no importa el project.json, también puede definir las propiedades de su proyecto en el csproj.

En realidad, es un cambio bastante fácil. Desde lo alto de mi cabeza tenemos que:

• Conserve el código dotnet-build existente y haga que se ejecute en determinadas circunstancias (por determinar).
• En otros, ejecutar MSBuild, según los planes de los equipos centrales de DotNet
• Haga que VS pueda leer project.json o MSBuild para las propiedades del proyecto
• Agregue la capacidad de Importar project.json a MSBuild

Una pequeña cantidad de trabajo, y le permite a Microsoft continuar su ruta de "MSBuild para siempre", y mantiene las promesas hechas a la comunidad .NET Core, y nos permite a aquellos de nosotros que queremos optar por no participar en MSBuild.

Es notable que nadie de los miembros de asp.net haya dicho nada aquí.

Mientras tanto, releí algunas de las notas de ASP.NET Community Standup - 10 de mayo de 2016 , y hablan de un "nuevo" sistema MSBuild, pero no digo qué es, excepto que no requerirá Visual Studio para editar. Apesta que no fue diseñado en asp.net y tiene que ser agregado (ahora) tan tarde en el juego ... cuando el diseño no incluía eso para empezar. Realmente, project.json solo debería incluir un elemento {"BuildSystem": "MSBuild"} si quieres / necesitas seguir esa ruta. También me pregunto por qué MS no pudo (las famosas últimas palabras) "simplemente" permitir comentarios en archivos json a través de las herramientas.

@rhires Según tengo entendido, el "nuevo" sistema MSBuild son algunos ajustes para hacer que el XML sea un poco más ligero, como incluir todos los archivos cs en la compilación y descargar las dependencias a un archivo nuget.json. Sin cambios significativos en el diseño, la arquitectura o el uso de MSBuild.

Me gusta tu idea de project.json. Solo estaba pasando por los cambios de RC2, y pusieron "testrunner", así que no hay ninguna razón por la que no se pueda hacer. _PERO_, parece que sus corazones están completamente decididos a eliminar project.json por completo y volver a un mundo de MSBuild-first.

por qué MS no podía (últimas palabras famosas) "simplemente" permitir comentarios en archivos json a través de las herramientas

No hay ninguna razón por la que no puedan. JSON.Net, la biblioteca que utilizan, admite comentarios.

Realmente, project.json solo debería incluir un elemento {"BuildSystem": "MSBuild"} si quieres / necesitas seguir esa ruta.

¿Por qué querría que mi proyecto dictara su propio sistema de compilación? ¿Seguramente el sistema de construcción construye el proyecto y no al revés?

@neoKushan :

recuerde que la razón principal por la que Microsoft está impulsando las definiciones de proyectos de MSbuild es para ayudar a facilitar la migración de aquellos que han invertido mucho en MSBuild. En ese sentido, Paket no es mejor que project.json (o project.yaml o project.cs o lo que sea).

Paket no es un nuevo sistema de compilación, es un administrador de dependencias que es 100% compatible con MsBuild. Simplemente resuelve el problema de packages.config .

@ Krzysztof-Cieslak Nunca dije que fuera un sistema de compilación y la gestión de dependencias no es realmente un problema importante con .net core (que yo sepa, al menos). .net core no usa packages.config , usa project.json .

Si .Net Core todavía estuviera planeado para usar project.json , no tendríamos esta discusión de 100 publicaciones. ;) Todo lo que estoy diciendo es que la solución sugerida en muchos lugares de usar "nuget.json" para manejar dependencias es reinventar la rueda, ya que tenemos un producto que hace exactamente lo mismo.

@shederman

"Resultados finales de la encuesta: 100 respuestas, para una población de desarrolladores de .NET de 9 millones que es ± 10% con un 95% de confianza".

Sí, y preguntar en una conferencia sobre los juguetes para gatos cuál es la mascota preferida de un perro o un gato puede darte resultados similares.

@darrelmiller

"Creo que es importante hacer una distinción entre MSBuild y la forma en que Visual Studio usa actualmente MSBuild. He estado editando manualmente archivos de MSBuild durante años y los uso para todos mis proyectos. Por ejemplo, https://github.com/tavis- software / Tavis.home / blob / master / build / Build.proj "

¿Discutiremos los archivos de compilación específicos de VS en la parte superior de los archivos del proyecto donde msbuild no funciona desde la línea de comandos?

@gregoryyoung Deberíamos. He compilado archivos que dependen de devenv antes, pero no he visto los que no se ejecutarán desde la línea de comandos. ¿Algún ejemplo?

@gregoryyoung

Sí, y preguntar en una conferencia sobre los juguetes para gatos cuál es la mascota preferida de un perro o un gato puede darte resultados similares.

Esa es una analogía interesante. Excepto...

Publiqué el enlace en los feeds de Twitter de personas que _ apoyaron_ el cambio a MSBuild. Entonces, en realidad no se parece en nada a tu analogía.

Y me encantan los continuos insultos de que la encuesta fue parcial, en el foro equivocado o no científica. Pero, las preguntas no estaban dirigidas, las respuestas tenían una amplia gama de respuestas, y la encuesta, sí, era una audiencia autoseleccionada, pero amplia que, al menos en teoría, debería sesgar _al margen_ de mi punto de vista.

También tengo la impresión, y en algunos casos la confirmación, de que las personas que hacen estas acusaciones acaban de buscar en Google un poco sobre encuestas. Personalmente, he diseñado un protocolo de investigación a nivel de maestría para un estudio de salud, y aunque no afirmaré que la encuesta sea perfecta, ciertamente no es tan defectuosa como los empleados de Microsoft lo están haciendo.

Ciertamente _es_ estadísticamente significativo, y le está dando una buena indicación de dónde se encuentra la opinión. GitHub, gitter, Twitter y blogs lo respaldan en un grado u otro.

Varias fuentes de evidencia que dicen lo mismo. Si quieres ignorar las opiniones de un significativo de tus usuarios, dígalo. Deja de intentar rechazar su oposición como si perdieras el derecho a expresar tu opinión si mantienes la "equivocada".

O mejor aún, como he dicho muchas veces, crea tu propia encuesta que mejore las cosas que crees que están mal en la mía.

La razón por la que hice la encuesta es que estaba absolutamente claro que Microsoft no tenía ni idea de lo que pensaba la gente. Lo que se está volviendo absolutamente claro ahora es que no tienen ningún interés en lo que la gente piensa.

Dejen de ser deshonestos con ustedes mismos y con su comunidad y participen con la oposición en lugar de rechazarla.

Deje de intentar cambiar los hechos y comience a cambiar de opinión basándose en los hechos.

@shederman No tengo la impresión de que el equipo de Microsoft realmente haya respondido a este hilo (incluida su encuesta). Sí, un chico del equipo dijo que no lo consideraba tan confiable como tú, pero eso es todo. Creo que todavía hay esperanza de que actualmente estén hablando de la oposición masiva al camino que están tomando y están discutiendo sobre el camino correcto a seguir y nos responderán cuando sepan más.

Creo que podemos darle algo de crédito a este equipo;).

@gregoryyoung Lo siento, por la analogía que diste, asumí que eras un empleado de MS, ya que han estado diciendo la misma línea aproximada durante 2 días.

@sandorfr

Creo que podemos darle algo de crédito a este equipo

Pensé que podríamos, pero mis experiencias en los últimos días no han reforzado esa esperanza.

Tengo que pensar que no es culpa "del equipo", sino de alguien más alto en la organización que tomó esta decisión y la impuso ... y luego "el equipo" tiene que aguantar y hacer que se vea bonito. BTDT. No es divertido.

¿Todos se dan cuenta de que project.json ya ha experimentado grandes cambios recientemente para hacerlo un poco más compatible con aplicaciones que no son ASP.NET Core? Si solo mira el ejemplo en esa publicación de anuncio, ya se vuelve bastante hinchado con toda esa configuración de compilación.

Pasar de eso a un archivo csproj "clásico" en realidad no me parece tan difícil. Y si el propio csproj también evoluciona un poco en la dirección más flexible que hemos aprendido del project.json, puedo ver que el csproj "nuevo y mejorado" funciona realmente bien. Y creo que podemos asumir con seguridad que esos cambios recientes en project.json no habrían sido los últimos en el curso para hacerlo utilizable para _todos_ los proyectos .NET; creo que es importante que no olvidemos que hay hay muchos otros objetivos además de ASP.NET (Core).

Y en realidad no debería importar mucho si el formato de archivo es JSON, XML o lo que sea. Sí, uno puede ser favorable sobre otro por varias razones válidas, pero al final debe pensar cuánto tiempo realmente desea dedicar a un archivo de proyecto . Sí, con los problemas que hemos experimentado con los formatos actuales, pasamos más tiempo del que quisiéramos, pero lo ideal es que, suponiendo que solucionemos esas causas, deberíamos dedicar una fracción increíblemente pequeña de nuestro tiempo a esos archivos. Y en ese momento, no debería tener que preocuparse por el formato en el que se encuentra. Especialmente si eventualmente es todo asistido por herramientas (incluida la finalización completa en los editores).

Siento que cuando la gente piensa en project.json, piensan principalmente en las primeras etapas, que se trataba mucho de la convención sobre la configuración. Sí, eso fue muy bueno, pero también muy específico para ASP.NET Core y, como tal, muy limitado. Realmente no funcionará bien para otros objetivos, por lo que tiene sentido usar algo que ha funcionado bien durante muchos años y expandirlo y mejorarlo en todas las formas posibles mientras se mantiene la compatibilidad.

Entonces, tl; dr: Sí, realmente me gusta project.json y desearía que hubiera una manera de mantenerlo para ASP.NET Core (por ejemplo, usando una tarea especial de MSBuild). Pero al mismo tiempo, entiendo completamente por qué está sucediendo esto ahora, y creo que en realidad no es algo malo que hagan. Por supuesto, el momento es un poco extraño, pero dado que el cambio no ocurrirá en paralelo a la versión de ASP.NET Core y .NET Core, no creo que el momento sea un problema real (asumiendo que la transición posterior será sin problemas ).

necesidad de poder compartir archivos fuente entre proyectos

@darrelmiller Esto me parece aterrador, porque parece implicar que la lista de archivos en .csproj está volviendo.

@lokitoth Suponiendo que csproj funcionará de manera similar para las referencias de archivos como el project.json más nuevo, no hay nada que le impida usar globs en general y tener referencias de archivos individuales junto con ellos.

@shederman No soy un empleado de MS, solo una persona racional. Si me buscas en Google, estoy seguro de que puedes encontrar que tengo un interés a largo plazo en la plataforma.

Hay muchos pros y contras asociados con el cambio, pero lo que ha proporcionado no es útil para ninguna discusión sensata.

Este fue un cambio decepcionante. project.json, la inclusión / globalización automática de archivos y la restauración transitiva fueron las primeras cosas sobre ASP.NET Core que me hicieron decir "¡oh, bueno!" al principio.

Me doy cuenta de que no todo eso desaparecerá (¿espero?). Pero volver a un archivo de proyecto XML se siente mal, porque históricamente eso ha significado dolores de cabeza para los humanos. Odio abrir un archivo csproj para solucionar un problema porque es un muro de texto difícil de analizar.

Solo mis dos centavos.

Mirando los cambios en la publicación de

Basado en el hecho de que quieren admitir las opciones de Compilar, Incrustar, Copiar a Salida, Excluir, Archivos Compartidos, etc., entonces realmente el formato json no iba a funcionar mejor que XML de todos modos. También sospecho que json no habría funcionado tan bien para personalizaciones de scripts de compilación pesadas.

Solo espero que este sea el equipo que está tratando de no agregar otra solución a medio hornear a la producción hasta que tengan tiempo de encontrar una manera de hacerlo bien.

@gregoryyoung lo que ha proporcionado no es útil para ninguna discusión cuerda

Estupendo. Bien, veamos, qué he proporcionado:

• Me he quejado del cambio a XML, al igual que una gran cantidad de otros
• Me he quejado del cambio a MSBuild, al igual que una gran cantidad de otros
• He intentado comprender las razones y la evidencia detrás de la decisión, que en realidad no se ha proporcionado, además de algunas cosas muy onduladas.
• He intentado llegar al _pensamiento_ subyacente detrás de la decisión, que _tampoco_ realmente no se ha proporcionado
• Le he pedido a la comunidad sus opiniones, lo que MS no se ha molestado en hacer en absoluto.
• He tratado de encontrar alternativas que permitan los resultados declarados por las personas que dan las razones, pero también permiten que la comunidad mantenga su proceso de construcción simple que les gusta.
• Me he ofrecido a hacer el trabajo necesario para apoyar dichas alternativas.

¿Puedo preguntar, por interés, cuál es la parte loca? ¿Interrogar el pensamiento de alguien no es racional en estos días? ¿O dejé algo ahí fuera?

Quiero decir, estoy enojado , no me malinterpretes. He desperdiciado una gran cantidad de trabajo, tiempo y dinero construyendo alrededor de una promesa central del marco que se ha eliminado en el último minuto en lo que parece ser un movimiento precipitado y mal pensado. ¿No tengo derecho a enfadarme?

PD. Ah, eres _ ese_ Greg Young. Respeto. Amo tu trabajo. Realmente lo hago.

@bzbetty Estoy totalmente de acuerdo contigo. Lo último que me gustaría ver es una reinvención de MSBuild en project.json. Uno de los mayores problemas con MSBuild en su forma actual es que combina una _definición de proyecto_ con un _proceso de compilación_.

Entonces, ir y agregar un proceso de compilación en project.json estaría cometiendo exactamente el mismo error que cometió MSBuild / VS.

La definición del proyecto debe estar separada del proceso de construcción e incorporarse al proceso de construcción.

Y luego uno tiene que preguntarse: si su proyecto es simple y solo necesita construir directamente la definición del proyecto, ¿realmente necesita un sistema de construcción pesado, extensible, personalizable, flexible y contrario a la intuición solo para hacer una construcción simple?

Dicho de otra manera. Si tuvieras una definición de proyecto tan simple y una herramienta de compilación muy simple que no pudiera hacer nada más que compilar la definición del proyecto, ¿elegirías instalar y usar un MSBuild o un NAnt o algo similar?

No, probablemente no, ¿verdad? Me refiero a por qué agregar innecesariamente a la complejidad. Una parte fundamental de la práctica eficaz de la ingeniería de software es simplificar las cosas.

Pero, ¿una vez que se encuentra en un escenario que la simple herramienta de "construir la definición" no puede manejar? Seguro, entonces lo harías.

Estoy diciendo, instale ambas herramientas una al lado de la otra, para que podamos elegir cuál es la mejor para nuestras necesidades. Los MS están diciendo: no, solo necesita la herramienta compleja y contra-intuitiva, pero eliminaremos las características más notoriamente malas.

Soapboax

Solo me gustaría compartir un poco de investigación que he estado haciendo. He estado mirando Twitter, Slack, Github, Gitter y Jabbr.

He visto muy poco apoyo para el movimiento fuera del equipo central. Quiero decir, ha habido algunos, pero no muchos. La mayoría de la gente está bastante molesta por la mudanza.

También me ha consternado bastante la tendencia de muchos en el campo pro-MSBuild a inferir que sus oponentes están mal informados o, más comúnmente, no calificados. Esto ha sido igualado por la tendencia en el campo pro-project.json de inferir malos motivos (incluido yo mismo, mea culpa).

Me gustaría preguntar lo siguiente:

• La gente asume que las personas que tienen opiniones diferentes a las suyas las tienen por buenas razones. No son engañados, incompetentes, cómplices o locos
• Personas para atacar argumentos y pruebas y no personas
• Cualquier prueba proporcionada no debe descartarse de inmediato sin razones firmes.

Argumentos para
Las principales razones que he visto avanzadas para el cambio a MSBuild son:

• Soporte de herramientas: para permitir el disparo de ida y vuelta entre diferentes herramientas, por ejemplo, VS, VSCode, Xamarin, etc.
• Inversiones existentes: los grandes clientes tienen construcciones existentes que no pueden permitirse el lujo de deshacerse de ellas.
• "Memoria muscular": la gente está acostumbrada a MSBuild

Argumentos en contra

• Inversiones existentes: inversiones realizadas en herramientas de .NET Core: post RC. RC _debería_ significar que no hay cambios importantes
• CSProj / MSBuild desagradable: experiencias negativas pasadas al tratar con csproj y MSBuild
• Paso atrás: pasar a project.json fue un cambio a una nueva forma de trabajar, en parte para atraer a una nueva generación de desarrolladores. Esto se esta deshaciendo

Opinión
He pagado una suscripción completa a SurveyMonkey para poder acceder al conjunto completo de resultados (en lugar del primer centenar). Son 321 respuestas, lo que normalmente se traduciría en un margen de error de ± 5,5%, un 95% de confianza para una población de 9 millones.

Los argumentos comunes que he escuchado en contra de esta encuesta son:

• Las preguntas / respuestas están sesgadas: no creo eso, e incluso si lo son, no lo son por mucho. Existe una amplia gama de respuestas.
• La encuesta se envió a una audiencia sesgada: ¿Twitter? A los seguidores de las distintas líneas de tiempo de los miembros del equipo. No estoy seguro de cómo es una audiencia sesgada.
• No científicamente relevante: está bien, me puso en este. No hice un protocolo de investigación completo, por lo que no pasaría la revisión por pares. ¿Es ese el nivel de certeza necesario para evaluar el apoyo a una propuesta?

Aquí están:

Mi llamamiento para todos los que aman el marco .NET es que no subestimen el nivel de angustia por estos cambios, y que tengan en cuenta los comentarios e interactúen con la comunidad sobre la base de que sus preocupaciones son válidas y provienen de una experiencia informada. .

Y si la decisión es seguir adelante independientemente, se debe proporcionar un mejor conjunto de razonamientos y pruebas que hasta ahora.

El hombre @shederman me recuerda a mí (y a muchos otros) cuando Silverlight se lo comió , excepto x10 y más concentrado / experimentado. Probablemente por eso lo apoyo: 100:%! ja ja.

Uno de los mayores problemas con MSBuild en su forma actual es que combina una definición de proyecto con un proceso de compilación.

Entonces, ir y agregar un proceso de compilación en project.json estaría cometiendo exactamente el mismo error que cometió MSBuild / VS.

La definición del proyecto debe estar separada del proceso de construcción e incorporarse al proceso de construcción.

: +1:: +1:: +1: ... ¡¡¡Excelente manera de enmarcar el problema !!! Sabes, he metido mi nariz en esto durante tanto tiempo, que en realidad nunca se me ocurrió. Pero estás (de nuevo) 100% en el punto.

Odio abrir un archivo csproj para solucionar un problema porque es un muro de texto difícil de analizar.

¡Esto debe estar enmarcado en alguna parte, @nbarbettini! Captura perfectamente mi sentimiento también.

Y en realidad no debería importar mucho si el formato de archivo es JSON, XML o lo que sea.

Sí, odio intentar recordarle esto a la gente, pero parece que algunos desarrolladores están pegados a la noción de formatos, y eso es engañoso. El paradigma del proyecto "JSON" no es realmente una "cosa JSON", sino que utiliza JSON como su opción de serialización para describir su "modelo". El hecho de que JSON sea conciso y menos hablador que XML lo hizo aún más atractivo (para la mayoría).

En consecuencia, MSBuild no tiene sus raíces en XML, per se, pero la forma en que ha sido diseñado es para que su "modelo" se describa en este formato. Digo "modelo" porque ambos sistemas adolecen de (lo que considero un) defecto de diseño al colocar un modelo de documento delante del modelo / API real que finalmente se deserializa en la memoria. Eso significa tener que administrar más artefactos y conceptos de los realmente necesarios y, en última instancia, complica el sistema. Codificarlo para que solo acepte un formato en particular (XML o JSON) solo lo empeora, y nuevamente debemos explorar formas de mitigar esta restricción.

De todos modos, PSA del domingo por la mañana para todos. : Lengua_salida_atascada:

No pude ver esto publicado en ninguna parte de este hilo, así que aquí va ... https://youtu.be/N9MteJH-HsQ. Ojalá explique un poco más por qué se está realizando el cambio.

@shederman

"¿Puedo preguntar, por interés, cuál es la parte loca? ¿Interrogar el pensamiento de alguien no es racional estos días? ¿O dejé algo ahí afuera?"

Me refería a los resultados de la encuesta y trataba de extrapolarlos a la población general de desarrolladores. Como mencioné, es aproximadamente equivalente a realizar una encuesta en la que se muestran mejores perros que gatos en una convención de juguetes para gatos y suponiendo que se aplique a la población en general, existe un sesgo de muestra grande y obvio.

GitHub en mi teléfono no me deja +1 @gregoryyoung , sino +1.

El equipo ha explicado que parte del motivo del cambio es la adquisición de Xamarin, que es un gran problema. El potencial para compartir bibliotecas entre .NET, ASP.NET y proyectos Xamarin mobile / x-plat es inmenso, y si eso significa comprometer el formato de archivo del proyecto / compilación, en mi humilde opinión vale la pena negociar.

Voy a esperar y ver cómo se ven las herramientas y la configuración del archivo final antes de formar una opinión final.

@gregoryyoung Me estaba refiriendo a los resultados de la encuesta y tratando de extrapolar a la población general de desarrolladores ... hay un sesgo de muestra grande y obvio.

¿Qué sesgo muestral sería ese? ¿En el que se publicó principalmente en los feeds de Twitter de personas a las que les _ gusta_ los cambios? ¿En el que estaba en los canales flojos que usa el equipo de desarrollo?

El principal sesgo de la muestra que veo es que los encuestados probablemente estén comprometidos, informados y apasionados. Claro, es probable que no sea una muestra representativa, pero yo diría que es importante. E incluso con el sesgo de la muestra, ¿significa eso que los resultados deben desecharse? ¿Que los puntos de vista de los encuestados no importan?

322 desarrolladores profesionales de .NET han expresado una opinión. ¿Va a ignorar totalmente su entrada porque cree (sin ninguna evidencia que lo respalde) que no es representativa?

Aparentemente, una publicación de blog llegará la próxima semana, tendremos cosas más específicas para discutir entonces.

Por Dios, la gente necesita calmarse :)

Estoy de acuerdo en que este cambio parece grande, pero creo que afectará a la gente mucho menos de lo que parece. Recuerde que cuando el equipo habla de "herramientas", eso también incluye el cli. Cualquier conversión que deba ocurrir también será realizada por el cli, "herramientas" para agregar referencias, que yo sostengo que es incluso mejor que escribirlas en json o xml, estará en el cli. Globbing ya es compatible con msbuild. Obviamente, Msbuild se incluirá en don't sdk, por lo que no habrá instalaciones adicionales, la historia del nuevo proyecto también será la misma, los comandos dotnet solo harán otras cosas bajo el capó. (No soy microsoftie, pero esto parece muy probable)

El equipo no son idiotas, no hacen este cambio a la ligera. Han _han_ dado_ razones, principalmente compatibilidad y coherencia con el resto de la plataforma en todos los idiomas, referencias nativas y tipos de proyectos, granularidad de paquetes nuget, etc. Solo ha pasado una semana y han dicho que muy pronto detallarán los cambios y su razonamiento.

Desearía que la gente al menos esperara eso y cuáles son sus planes reales antes de condenar la medida por completo.

Y sí, he depurado manualmente archivos csproj / tfproj y he luchado contra las reglas condicionales para la inclusión de archivos y todo eso. Diablos, incluso he escrito tareas de compilación personalizadas. Pero al final del día, es mucho más fácil abstraer un sistema complejo con herramientas simples (cli incluido), en lugar de hacer que el relativamente simple sistema project.json admita todos los escenarios complejos que necesita.

Dicho de otra manera, esa simplicidad que a la gente le encantaba en project.json ya se había ido, necesitaba ir para soportar la compleja realidad de un entorno dotnet generalizado con todo tipo de proyectos y escenarios. Si hubieran implementado todo eso en project.json, básicamente tendrías msbuild nuevamente. Prefiero que den un paso atrás y miren el sistema de compilación como un todo en lugar de agregar característica tras característica a project.json hasta que se convierta en una gran bola de espagueti.

Veamos lo que están sugiriendo y luego planteemos problemas específicos si encontramos fallas en eso :)

@ aL3891

Si el equipo explica claramente su razonamiento y las alternativas que se consideraron, y por qué fueron rechazadas, y también considera y se compromete con las propuestas que se han sugerido aquí, entonces estoy de acuerdo con eso y apoyaré cualquier solución bien razonada que sale de tal proceso.

De hecho, esto es exactamente lo que he estado pidiendo desde hace tres días. Información sobre el proceso de toma de decisiones y la evidencia que lo respalda. La información que se ha proporcionado hasta ahora a este respecto ha sido, en el mejor de los casos, decepcionante.

Si lo conseguimos, +10 de mi parte.

@ aL3891 Pregunta rápida. Algunas personas decían que deberíamos asistir al stand del miércoles para abordar estos problemas. ¿Estás diciendo que deberíamos esperar a la publicación del blog?

Todo el mundo debería recordar también que todo esto es de código abierto. Si cree firmemente que lo que no es msbuild es mejor, simplemente bifurque las herramientas existentes y continúe. Como ocurre con todas las opciones de diseño de software interesantes, existen pros y contras para todos los lados del argumento. Microsoft necesita responder a sus grandes clientes de pago, pero para su crédito, han hecho todo esto de código abierto. Si algo más te funciona, hazlo.

Vi ese video de youtube que @khellang publicó: los cambios de ASP.NET fueron _revolucionarios_, pero parece que, al final, fue demasiado revolucionario, y ahora con Xamarin en la mezcla, _revolutionary_ no va a ser suficiente.

Además, la idea de reinventar la rueda no parecía atractiva, cuando parecía que en realidad era lo correcto ... pero legado de nuevo.

Tengo una crítica nueva sobre el uso de MSBuild, basada en el standup de .NET, mientras que tenemos una buena separación de preocupaciones en varios lugares, MSBuild no. Aproximadamente, según el standup, de alguna manera tiene que saber todo para ser efectivo, y simplemente orquestar diferentes piezas no es lo suficientemente bueno.

Mientras tanto, y creo que esto debería ir en otro hilo: parece que hay "decisiones de ingeniería internas" que luego se comparten con la comunidad. Esto me hace pensar que la EM no se vuelve completamente de código abierto: si hubieran tenido estas discusiones abiertamente (y hubieran hecho que la gente se diera cuenta de que estaban ocurriendo), habría sido una sorpresa menor y es posible que ya tuviéramos respuestas, y muchas partes interesadas (y me refiero a los clientes que se verían afectados negativamente por un abandono de MSBuild) podrían haber dado a conocer claramente sus posiciones antes, y la comunidad podría haber reaccionado de manera más oportuna sobre problemas / inquietudes e incluso soluciones a la problemas presentados ... En cambio, "era nuestra única opción", es la razón por la que abre el código no sólo el software, sino también el proceso de desarrollo. Así es como se supone que funciona la máxima "dados suficientes ojos, todos los errores son superficiales". No sé qué tan grande es el equipo de ingeniería en MS, pero es más pequeño que la comunidad en general, y hay algunos talentos realmente buenos en la comunidad que podrían estar preparados para un desafío como el que el equipo de ingeniería decidió que no era viable. ... y probablemente lo sea para ellos, pero no para la comunidad en general. El código abierto se trata de utilizar los recursos y el talento sin explotar que existen.

Por otro lado, ¿tal vez me perdí algo en alguna parte?

@shederman Sugeriría a aquellos con un interés personal que asistan al standup y estén atentos a la publicación del blog (que seguramente estará vinculada aquí).

Para aquellos que desconocen el standup, vaya aquí: https://live.asp.net/

Puede agregarlo a su calendario y es un reloj que vale la pena incluso si no le importa el cambio de definición del proyecto.

@shederman No siento que realmente tenga autoridad para decirle a nadie qué hacer, pero puedo decirte lo que haré. Diablos, soy un forastero al igual que el resto, no _ sé_ nada :) Creo que los standups y los programas de on.net son una gran fuente de información, especialmente los primeros indicios de lo que se avecina, así que ciertamente veré aquellos. si dicen que llegará una publicación de blog, al menos les daré el beneficio de una duda y veré qué tienen que decir. Pero probablemente dejaré comentarios / haré preguntas sobre ambos.

Sin embargo , el último

También está el repositorio del sistema de proyectos de roslyn que probablemente verá mucha acción en los próximos meses.

¿Alguien tiene un TL; DR en el episodio de on.net?

Creo que soy muy inusual en _ odiar_ ver videos sobre programación. Dame un mensaje de texto en cualquier momento 😄

¡Maldito infierno! Incluso no soy IDE en mis métodos de aprendizaje 😱

Creo que soy muy inusual al odiar ver videos sobre programación. Dame un mensaje de texto en cualquier momento: sonríe:

¿Cuál es el problema? Es _sólo_ una hora de su tiempo. :sonrisa:

@rhires

Tipo. ¡Es muy posible que sea una de las mejores publicaciones que he visto sobre este tema en los últimos 3 días!

Pequeño precio a pagar para permanecer a la vanguardia en mi opinión, pero para cada uno lo suyo;)

TL básico; dr:
El equipo comenzó a recibir comentarios tanto de clientes internos como xamarin como de clientes externos de que la migración de proyectos existentes a project.json era difícil y lograr que project.json trabajara junto con proyectos existentes, así como con otras cadenas de herramientas, como las nativas y las de otros. plataformas como Android significarían traer una cantidad significativa de código (o conceptos) de msbuild. Esto llevaría mucho tiempo y esfuerzo y retrasaría el lanzamiento por una cantidad de tiempo inaceptable, además de ralentizar el trabajo futuro (incluso para otros productos como xamarin studio y mono development, así como para desarrolladores de plugins de visual studio).

En su lugar, optaron por basar el sistema de compilación en msbuild, pero incorporaron las cosas que a la gente le gustaban del nuevo sistema. En cuanto al momento, la adquisición de xamarin no se conocía ni siquiera cuando se hizo RC1, pero ahora que se hizo, cambió muchas cosas.

También reconocen que a la gente le gusta mucho project.json y a ellos también, y que quieren retener la mayor parte de la bondad de eso, tal vez incluso permitiendo que msbuild lea archivos project.json también a través de un destino. Los escenarios Cli y VS-less también es algo que ven como un escenario central. También hablan un poco sobre otros sistemas de compilación y el objetivo es permitir que las personas usen otras cosas además de msbuild si así lo desean.

Luego hablan un poco sobre RC2 y lo que se envía allí y también reflexionan sobre lo que podrían haber hecho de manera diferente con respecto a la migración del sistema del proyecto, ser más abiertos antes y tener más conversación en GitHub, etc.

Recomiendo verlo, probablemente me estoy perdiendo algunos puntos más finos aquí.

@ aL3891 - gracias por el gran resumen. Fue un trabajo duro leer el video. Estoy de acuerdo en que deberían redactar un resumen de texto. Me di cuenta de que están "aprendiendo" y todavía se sienten incómodos con la apertura de su proceso, incluso cuando dicen que es algo bueno. Así que, con suerte, esta será una buena experiencia de aprendizaje para ellos y veremos los cambios y seremos beneficiarios de ellos.

@ aL3891 ¡ Gracias por el resumen!

Pequeño precio a pagar para permanecer a la vanguardia en mi opinión, pero para cada uno lo suyo;)

Ah, pero no estoy en el borde de la sangría, me quedo un poco hacia atrás desde allí. Lo suficientemente atrás como para no cortarme, o al menos eso pensé cuando adopté .NET Core post-RC1 😢

@shederman dado que "post-RC1" es básicamente nocturnos de origen o, ¿cómo es exactamente lo que te gusta el filete?

@neoKushan Quise decir que solo "adoptamos * .NET Core _después de que se lanzó RC1. Todavía estamos en vainilla RC1.

Entonces, nos gusta nuestro filete medio crudo. Pero cortamos un trozo realmente crudo y estamos llamando al camarero a gritos.

Pero está bien, dejé de llamar al camarero y ahora llamé al maitre (nuestro representante de socios de Microsoft Group) para que venga a verme y podamos discutir la toma de decisiones, la difusión de información y la dirección de la plataforma.

¡No sabemos nada!

No se nos ha dado suficiente información, demasiada teoría y conjeturas en este número. Resumen rápido para los perezosos que no quieren leer este hilo:

Lo que sabemos

1. xproj se convertirá a csproj.
2. "Podríamos" tener un archivo nuget.json.
3. Estamos usando msbuild .
4. Todo esto sucederá por etapas.
5. Las bibliotecas no cambiarán.
6. No tendrá que especificar todos los archivos en csproj.

Lo que aún no sabemos

1. ¿Se compilará csproj en .nupkg?
2. ¿Se compilará csproj en múltiples arquitecturas y destinos a la vez x86 / x64 dotnet / dotnetcore?
3. ¿Habrá un archivo nuget.config separado?
4. ¿Cómo se manejarán los comandos para ejecutar npm / gulp / bower / etc.?
5. ¿Podremos usar dotnet build así como msbuild ? Estoy totalmente a favor del 'one .net' al que aspira @shanselman .
6. ¿Las referencias de intellisense para proyectos permanecerán o desaparecerán?
7. ¿Las herramientas de VS o la línea de comandos serán lo suficientemente buenas como para que nunca tengamos que editar el archivo csproj.
8. ¿Obtendremos herramientas de dotnet add reference MyAssembly ?

Creo que este problema debería cerrarse hasta que tengamos más información.

Estoy totalmente a favor del 'one .net' al que aspira @shanselman .

Este ? : sonrisa:: +1:: +1:: +1:

Creo que este problema debería cerrarse hasta que tengamos más información.

pero pero pero ... entonces que haré con mi vida ??? : llorar:: sonrisa:

@RehanSaeed

¿Y si tengo problemas con la lista "Lo que sabemos"?

¿Debo esperar a que se aclare la lista de "Lo que aún no sabemos" antes de plantear mis inquietudes?

¿O debo callarme y aguantarlo?

Como bien sé, a muchas personas les gustaría ... 😉

De todo lo que he visto, la decisión es 100%, inalterable en:

Entonces, ¿qué más necesito de "Lo que aún no sabemos"?

@shederman Es posible que desee ver el video de On.Net. Da un montón de razonamientos detrás de la decisión.

Fyi: Normalmente cambio la velocidad a 1,5 para verlo más rápido. https://www.youtube.com/watch?v=N9MteJH-HsQ

Si vamos a quedarnos con un archivo de proyecto basado en XML, por favor, POR FAVOR, ¿puede sugerir / alentar / requerir que las herramientas pongan el contenido del archivo en algún tipo de orden? Y "cronológico" NO es un orden aceptable. El mayor problema que he encontrado con los archivos proj es la dificultad para fusionarlos. Simplemente alfabetícelos al menos. Sí, todavía tendremos el problema de fusión ocasional, pero tomaré "ocasional" en lugar de "omnipresente" cualquier día.

@MelGrubb lo único que sabemos es que el nuevo diseño del proyecto NO enumerará todos los archivos presentes, será como lo hace project.json

Para cualquier cosa que se espere que sea administrada a mano, TOML por favor.

JSON no tiene ningún sentido para la configuración. Tiene incluso menos sentido que XML.

Para cualquier persona interesada, parece que los bits RC2 están disponibles (aún no hay publicación de blog que pueda ver)

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

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

Mis dos centavos, fwiw:

Me ha encantado la sencillez de project.json. Esto es lo que me gustaría (y no me gustaría) ver en las herramientas basadas en MSBuild:

• MSBuild no debe estar vinculado a VS ni a ningún otro IDE / editor. Debe ser una herramienta independiente que se pueda instalar por sí sola. (O incluido como parte de la instalación de dotnet cli). Digo esto porque tuve que instalar una instancia VS completa en agentes de compilación solo para obtener MSBuild. Eso nunca tuvo sentido para mí.
• MSBuild (o dotnet cli que contenga MSBuild) en sí mismo debería ser instalable con una línea de comando, ya sea apt-get, chocolately, homebrew, powershell o bash / curl. Si no puedo instalar esto como parte de una configuración completamente automatizada de un agente de compilación (por ejemplo, en circle.yml o Dockerfile), será un obstáculo y una fuente de dolor.
• MSBuild debería ser muy compatible con la línea de comandos. Debería poder hacer cualquier cosa desde la línea de comandos y, por lo tanto, poder automatizar cualquier cosa en un proceso de compilación, en un circle.yml, bash u otro archivo de script. Y me gustaría ver un buen uso de stdin y stdout, para poder entrar y salir de los comandos de MSBuild.
• Trabajar en un proyecto .NET Core en VS Code (u otro editor que no sea VS) no debería requerir información específica de VS en un archivo csproj o en cualquier otro lugar. La información del proyecto, las dependencias de paquetes nuget, los objetivos de la plataforma, las directivas del compilador, etc., deben poder compartirse entre los desarrolladores que utilizan diferentes IDE / editores. Aquellos tienen sentido en un archivo de proyecto. Pero las personas que no usan VS no deberían tener que ver la configuración de las herramientas de VS, ya que pertenecen a un archivo separado.
• Los archivos del proyecto deben ser fáciles de entender y editar a mano. Las herramientas son increíbles, pero debería poder abrir el archivo y comprender lo que las herramientas están haciendo por mí. Y realice cambios fácilmente.
• Aunque sé que no hay diferencia en la funcionalidad / capacidad, tengo una fuerte preferencia personal por json sobre xml. También creo que el uso de json ayudará a atraer desarrolladores de otras pilas. Ya es bastante difícil atraer a la gente a .NET sin convertir una de las primeras cosas que ven en un archivo XML grande y difícil de descifrar. (Esto es más emocional que lógico, pero creo que importa). Por favor, al menos haga de json una opción y use esa opción en generadores de yeoman y otras plantillas de proyectos nuevos. En el peor de los casos, acepte rápidamente la inevitable solicitud de extracción que implementa un formato json simple en el repositorio de MSBuild.
• Sería bueno mantener los "scripts" de estilo npm, para que pueda compartir fácilmente los comandos utilizados para desarrollo, prueba, depuración, compilación, ejecución, compilación / ejecución de la ventana acoplable, etc. con mi equipo. Esos podrían ir en sus propios archivos de script, pero tienen sentido (para mí) como parte del archivo del proyecto.

@jtbennett

"Pero las personas que no usan VS no deberían tener que ver la configuración de las herramientas de VS, que pertenecen a un archivo separado".

Solo para agregar, ahora también hay un montón de cosas en otros archivos que probablemente deberían colocarse en el archivo msbuild. Las cosas ignoradas son un buen ejemplo de esto, ya que los archivos de proyecto aún son compatibles. No puedo decirte cuántos proyectos he visto que se construyeron en VS pero no desde la línea de comandos

@jtbennett

MSBuild no debe estar vinculado a VS ni a ningún otro IDE / editor.

No estará vinculado a VS en absoluto, se entregará a través de Nuget, por lo que no estará vinculado a nada.

MSBuild (o dotnet cli que contenga MSBuild) en sí debería ser instalable con una línea de comandos

Esto no cambiará a partir de hoy, aún podrá instalar dotnet cli a través de las fuentes de paquetes habituales.

MSBuild debería ser muy compatible con la línea de comandos.

_MSBuild_ será efectivamente parte de la compilación en sí, por lo que no creo que deba pasar las opciones de la línea de comandos. Sin embargo, donet (CLI) obviamente será compatible con la línea de comandos y creo que esto es todo lo que quiere / necesita.

Trabajar en un proyecto .NET Core en VS Code (u otro editor que no sea VS) no debería requerir información específica de VS en un archivo csproj o en cualquier otro lugar.

Estoy completamente de acuerdo con esto. Esperando que el "nuevo" formato de proyecto sea mucho más simplificado.

Los archivos del proyecto deben ser fáciles de entender y editar a mano.

Han dicho que esto también es una prioridad para ellos.

Aunque sé que no hay diferencia en la funcionalidad / capacidad, tengo una fuerte preferencia personal por json sobre xml. También creo que el uso de json ayudará a atraer desarrolladores de otras pilas. Ya es bastante difícil atraer a la gente a .NET sin convertir una de las primeras cosas que ven en un archivo XML grande y difícil de descifrar.

Encuentro esto interesante, personalmente creo que XML es mucho más fácil de descifrar que JSON, pero creo que mucho de eso se reduce a lo bien diseñado que esté el esquema (para cualquiera de los dos). Tuve que descifrar un XML espantoso en el pasado con nombres de elementos realmente horribles (como "Elemento") y aunque MSBuild no es de ninguna manera el peor infractor en ese sentido, ciertamente deja mucho que desear. Con JSON, el nombre de la clave puede sufrir los mismos problemas.

Como anécdota, recientemente tuve que trabajar en un proyecto en el que alguien intentó incrustar JSON en elementos XML :(

Publicación de blog RC2 ahora disponible: https://blogs.msdn.microsoft.com/webdev/2016/05/16/announcing-asp-net-core-rc2/

La publicación .net core también está activa https://blogs.msdn.microsoft.com/dotnet/2016/05/16/announcing-net-core-rc2/

¡Gracias @neoKushan !

@michaelvolz No creo que ese archivo se quede, si hay que creerlo: https://github.com/dotnet/cli/blob/rel/1.0.0/Documentation/specs/runtime-configuration-file .Maryland

System.GC.Server (antiguo: gcServer): booleano que indica si se debe utilizar el servidor GC (predeterminado: verdadero).

y

Podríamos usar un formato diferente para el archivo deps, pero si ya estamos integrando un analizador JSON en el host, parece más apropiado reutilizarlo aquí.

¿Parece un poco extraño que tengan XML para _project config_ pero .json para _runtime config_?

¿Parece un poco extraño que tengan XML para el proyecto pero .json para el tiempo de ejecución?

¿Lo hace ahora? :risa:

@ Mike-EEE ¡Buen punto! He actualizado para aclarar con suerte lo que quise decir: besar:

@neoKushan no, tenías razón la primera vez. : smile: Estaba de acuerdo contigo a mi manera sarcástica, casi contraproducente. : smirk_cat:

Pero sí ... 100% de acuerdo en que tener diferentes formatos dentro de una solución es enloquecedor. Tener un formato único en todos los ámbitos reduce la complejidad, el cambio de contexto y, por lo tanto, la _confusión_. Es una de las razones por las que quiero que MSBuild habilite diferentes formatos y se convierta en un formato independiente . Vaya, advertencia, enchufe desvergonzado. :sonrisa:

Creo que voy a ser un seguidor de tu santa cruzada @ Mike-EEE, ya que estamos atrapados con msbuild, hagámoslo mejor.

Hola, gracias @sandorfr ... siéntete libre de contribuir al hilo allí (incluso si es una reacción /: + 1 :). ¡Me siento un poco solo allí y definitivamente camino hacia un territorio en disputa! Desde mi perspectiva, estaría muy abierto a mejorar mi producto para aumentar la adopción / preferencia / usabilidad / simpatía si hubiera una gran cantidad de clientes obligados a usar mi producto por cualquier motivo. Pero yo no estoy a cargo de eso, entonces. : Lengua_salida_atascada:

@ Mike-EEE Leí parte del hilo, estoy tan deprimido ahora ... Entraste en el mundo heredado de las mentes heredadas: D.

Esperemos que la gente de Microsoft esté más abierta a sus ideas porque en realidad estoy bien con msbuild solo si la cosa se hace más simple y directa y no necesito una Gui para editar mi proyecto (sí, json intellisense fue mucho mejor que las pestañas habituales de proyectos de Visual Studio).

Entraste en el mundo heredado de las mentes heredadas: D.

Wellllll-dijo @sandorfr ... wellllll-dijo.

Para aquellos que desconocen el standup, vaya aquí: https://live.asp.net/

De acuerdo, soy un holgazán total y finalmente comprobé esto hace un momento. ¿Parece que el próximo standup es la semana que viene? ¿El equipo se salta esta semana?

@ Mike-EEE Interesante, definitivamente estaba programado para esta noche en un momento, pero me pregunto si ha cambiado. Tuiteé a @shanselman , espero que sea solo un error, pero dado que RC2 salió ayer, es posible que quieran omitirlo esta semana.

De acuerdo, genial @neoKushan ... solo asegurándome de que la cordura esté atornillada a mi cabeza por una vez. Ciertamente, tampoco me gustaría ser tan rápido al tratar con todas nuestras preguntas y descontento. :guiño:

de Slack:

jongalloway [9:31 AM] Estoy bastante seguro de que ASP.NET Community Standup mañana se cancelará; tanto shanselman como damianedwards están en OSCON.
...
davidfowl [9:34 AM] damianedwards: está de vuelta ... pero shanselman está en oscon
...
jongalloway [9:46 AM] Sí, ASP.NET Community Standup definitivamente se canceló para el 17/5. Actualicé el sitio.

@ Mike-EEE lidiando con todo nuestro ... descontento

😆

Por si quedaba alguna duda: https://twitter.com/shanselman/status/732585321775267842

tienes que saltar. Estoy en #vslive y OSCON

Hay una cosa que disfruto mucho con project.json: todos los archivos se incluyen por defecto en el proyecto, sin la necesidad de incluir explícitamente cada uno de ellos. Con proyectos grandes (me refiero a miles de archivos), el proceso de fusión fue realmente doloroso debido a XML, pero también porque todos los archivos se enumeran en el csproj.

¿Sabemos si va a haber alguna mejora de este lado?

@pierrus Se mencionó que no quieren volver a los días en que todos los archivos se enumeraban dentro de csproj.

@MaximRouiller OK, no lo sabía, ¡genial!

@MaximRouiller pero sí quieren volver a los días en que MSBuild era el Anillo Uno ™, me refiero herramienta de construcción. 😉

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

@shederman He moderado mi punto de vista desde mi primera reacción a la noticia.

Mi opinión es que inicialmente querían enviar el formato project.json , pero normalizar el modelo con csproj / Xamarin solo requeriría que impulsaran el marco aún más. La ganancia más rápida fue volver a fusionarse con csproj. Podrían mantener la nueva forma en un archivo separado mientras mantenían los "datos solamente" puros dentro del csproj. Eso para mí explica el enorme trabajo de RC2 que se hizo.

¿Si mueve propiedades que apenas cambian y mantiene las nuevas funciones geniales en un archivo separado? Realmente no perdemos nada. Sí, volveremos contra el monstruo ... pero no estamos demasiado lejos.

No tengo ningún conocimiento interno sobre esto. Esto es pura especulación de mi parte.

De todos modos ... ya no estamos terminando en un ciclo de lanzamiento anual. Si están listos para la transición de project.json a csproj post-RTM, supongo que también se podrían lanzar cambios más grandes después de RTM.

Cambios de los que nadie más que el equipo de MS tiene conocimiento.

@MaximRouiller No puedo trabajar con los cambios "posibles" que _podría_ estar por venir.

Simplemente trabajo con los cambios anunciados , que se están moviendo de la construcción liviana al uso de MSBuild y xproj para todo.

Sí, volveremos contra el monstruo ... pero no estamos demasiado lejos.

Um, si hemos _depreciado_ algo que funciona para el 90% de los casos de uso para mover _back_ a algo que es demasiado complicado para esos casos de uso, bueno, solo tengo una pregunta:

¿Por qué?

¿Por qué dotnet build llama a MSBuild cuando msbuild ya lo hace bastante bien? ¿Por qué desaprobar la construcción simple? ¿Por qué hacer un trabajo

algo que funciona para el 90% de los casos de uso

[cita requerida]

Incluso asumiendo que es el 90% de los casos de uso, ¿trabajaría con algo que fallara una décima parte del tiempo?

volver a algo que es demasiado complicado

Nuevamente, [cita requerida], lo único que sabemos hasta ahora es que será el XML-csproj y que no contendrá la lista de archivos. No sabemos nada más sobre cómo funcionará el sistema y no estoy convencido de que necesitemos saberlo, porque todos aquí simplemente llaman "compilación de dotnet" e independientemente de cómo se logre la compilación, eso no cambiará.

¿Por qué dotnet build llama a MSBuild cuando msbuild ya lo hace bastante bien?

¿Hemos pasado de decir que MSBuild es "demasiado complicado" a "MSbuild ya lo hace bastante bien"? Actualmente, dotnet build solo _ parece_ simple porque todo lo que sucede en segundo plano está oculto para usted. Cambiar a MSbuild no cambia esto, en lo que a usted respecta, sigue siendo solo dotnet build .

Para alguien que sigue diciendo que debe haber una distinción entre el sistema de proyecto y el sistema de compilación, no está dispuesto a aceptar que, de hecho, existe una diferencia entre tener archivos XML de MSBuild como sistema de proyecto y tener MSBuild como sistema de compilación. ya es una separación.

trabajando para el 90% de los casos de uso

@shederman Por favor, deje de suponer que todo es ASP.NET ... En este hilo, se muestra como _ voluntariamente ignorante_. Le sugiero que se calme por ahora hasta que obtengamos más información sobre el nuevo sistema de proyectos en lugar de simplemente asumir que todo está condenado al fracaso.

@shederman La razón por la que construye un calce sobre algo es cuando quiere reemplazarlo. Resúmalo para que pueda cambiar la implementación. Lo hacemos todos los días. Se llama refactorización.

Espero que sea reemplazado. Además del XML, creo que también es lento en comparación con otras cosas si no recuerdo mal.

Si es como dotnet build la pregunta es: ¿qué tan difícil será cambiar el proceso de construcción del subrayado? ¿Es posible reemplazar msbuild por algo diferente? ¿Cuántas cintas adhesivas necesitará?

Si pudiéramos hacer tal cambio en 1 o 2 madejas de cinta adhesiva, es aceptable.

@neoKushan ¿Hemos pasado de decir que MSBuild es "demasiado complicado" a "MSbuild ya lo hace bastante bien"?

Mmm no. Creo que estaba diciendo que el comando msbuild ejecuta MSBuild bastante bien. No estaba emitiendo juicios sobre MSBuild como herramienta. ¿No quedó claro?

@neoKushan Incluso asumiendo que es el 90% de los casos de uso, ¿trabajaría con algo que fallara una décima parte del tiempo?

Nadie está diciendo nada acerca de los fallos . Algunas herramientas son más adecuadas para algunos propósitos que para otros. Yo diría que el poder y la complejidad de MSBuild son adecuados para el propósito de aproximadamente el 10% de las compilaciones. Podemos discutir sobre los porcentajes exactos, pero definitivamente es menos del 100%.

@neoKushan Cambiar a MSbuild no cambia esto

Um, no cambia el proceso de construcción no. Sin embargo, _si_ cambia lo que se necesita para que funcione el proceso de compilación (es decir, el archivo csproj) y la velocidad a la que se realiza.

@neoKushan, no está dispuesto a aceptar que, de hecho, existe una diferencia entre tener archivos XML de MSBuild como sistema de proyecto y tener MSBuild como sistema de compilación; ya existe una separación.

Lo siento, pero no veo cómo tener una herramienta para hacer dos cosas es una separación.

@poke Por favor, deje de asumir que todo es ASP.NET

No soy. Estoy diciendo que la solución propuesta no funciona tan bien para compilaciones simples. Algunas de las cuales son compilaciones ASP.NET. Personalmente, tampoco veo por qué necesito algo tan poderoso como MSBuild para una aplicación de consola simple.

@poke Pareces ignorante deliberadamente en este hilo.

Eso espero, si. Porque lo que ignoro deliberadamente son los maravillosos beneficios que obtienen los usuarios de MSBuild.

@poke Te sugiero que te

Amigo, estoy tranquilo, te lo prometo.

Simplemente no estoy dejando que los puntos de vista con los que no estoy de acuerdo permanezcan sin oposición. Te prometo que no es señal de agitación. Por el amor de Dios, ni siquiera me agitó un pequeño idiota que me llamaba ignorante 😉

Lo cual es un poco irónico cuando este mismo pequeño idiota _persona_ me está pidiendo que me calme.

Realmente gracioso.

@MaximRouiller @shederman La razón por la que construyes un calce sobre algo es cuando quieres reemplazarlo. Resúmalo para que pueda cambiar la implementación

Ah, sí, y esa sería una buena razón para hacerlo, excepto por lo que he escuchado que no hay ninguna intención de reemplazar MSBuild. Es el sistema de construcción seleccionado para el futuro previsible. Me gustaría si permitimos que los proyectos se mantengan sin elementos específicos de MSBuild, y si dotnet build hiciera la compilación lite existente o seleccionara una herramienta de compilación basada en algo, por ejemplo, config. Si desea utilizar MSBuild, cree un archivo msbuild y ejecute msbuild .

Mmm no. Creo que estaba diciendo que el comando msbuild ejecuta MSBuild bastante bien.

Para poner esto en contexto:

¿Por qué dotnet build llama a MSBuild?

dotnet build hace mucho más que "simplemente" llamar al compilador, eche un vistazo a la implementación actual de la CLI de dotnet build . La construcción de un proyecto es solo parte del proceso dotnet build . Eventualmente, _parte_ de ese proceso será llamar msbuild pero ese no es su trabajo, ese es el trabajo de la CLI.

No estaba emitiendo juicios sobre MSBuild como herramienta.

Todo lo que ha hecho en este hilo es juzgar MSBuild como herramienta. Afirmar que no estás haciendo tal cosa es, francamente, ridículo.

¿No quedó claro?

Muy poco de lo que dice está claro, o al menos bien pensado.

Nadie está diciendo nada acerca de los fallos. Algunas herramientas son más adecuadas para algunos propósitos que para otros.

Por eso, algunas herramientas no son adecuadas para su propósito.

Yo diría que el poder y la complejidad de MSBuild son adecuados para el propósito de aproximadamente el 10% de las compilaciones.

Bueno, eso es interesante porque todos los desarrolladores de Visual Studio .net tendrían que estar en desacuerdo. De hecho, estás diciendo que MSBuild no es bueno para el 90% de los usuarios (ignorando el hecho de que estás sacando cifras de tu trasero), lo cual es, de nuevo, ridículo.

Um, no cambia el proceso de construcción no.

Si el proceso no ha cambiado, entonces su único argumento es que no le gusta la estructura del proyecto; el hecho de que sea MSbuild o lo que sea detrás del capó es completamente irrelevante .

Sin embargo, cambia lo que se necesita para que funcione el proceso de compilación (es decir, archivo csproj)

Eso es, literalmente, lo único que está cambiando en realidad, por lo que la gente verá.

y la velocidad a la que se realiza.

[cita requerida]

Muéstreme cómo el nuevo proceso es más rápido o más lento, dado que actualmente no existe .

Lo siento, pero no veo cómo tener una herramienta para hacer dos cosas es una separación.

Debido a que una herramienta no hace dos cosas, MSBuild puede ser el sistema de compilación, pero el cambio tiene que ver con el sistema del proyecto. No hay absolutamente nada que le impida usar un sistema de compilación diferente si lo desea, simplemente no es trivial.

No soy. Digo que la solución propuesta no funciona tan bien para compilaciones simples

dotnet new
dotnet restore
dotnet build

Muéstreme cómo la solución propuesta cambia algo sobre el escenario de "compilación simple"

Algunas de las cuales son compilaciones ASP.NET.

yo asp-net web
dotnet restore
dotnet build

Personalmente, tampoco veo por qué necesito algo tan poderoso como MSBuild para una aplicación de consola simple.

Tu no Solo necesitas dotnet build . Que todavía tendrás. Allí nada cambia.

Estoy tranquilo te lo prometo.

pequeño idiota

: -1:

@neoKushan Sería muy bueno si pudiera captar el concepto entre una respuesta a un extracto citado y un comentario sobre toda la discusión. Supongo que eres _capaz_ de hacer eso, así que la única conclusión es que es deliberado. Si es así, solo le hago saber que es una táctica intelectualmente deshonesta. Espero que lo supieras, pero te doy el beneficio de la duda aquí.

También creo que definitivamente deberías tomar una pastilla para enfriar. Solo estamos discutiendo lo que creemos individualmente que es mejor para el marco, no estamos tratando de _ pelear_ entre nosotros. Ataca el argumento, no a la persona. Bueno, eso es lo que he estado _intentando_ hacer durante bastantes días (excepto en un caso recientemente, ver más abajo).

Bueno, eso es interesante porque todos los desarrolladores de Visual Studio .net tendrían que estar en desacuerdo.

Es curioso, he recopilado pruebas que dicen algo diferente. ¿De dónde sacaste el tuyo?

Debido a que una herramienta no hace dos cosas, MSBuild puede ser el sistema de compilación, pero el cambio tiene que ver con el sistema del proyecto. No hay absolutamente nada que le impida usar un sistema de compilación diferente si lo desea, simplemente no es trivial .

Sí. Entonces estamos de acuerdo. Realmente me gustaría mucho si fuera trivial.

¿Es realmente una petición tan irrazonable? ¿En serio?

Tu no Solo necesitas la compilación de dotnet. Que todavía tendrás. Allí nada cambia.

¿Y dotnet build hará qué exactamente? ¿Desembolsar hasta msbuild ? ¿Por qué no podemos usar msbuild si queremos usar MSBuild? ¿Cuál es exactamente el propósito de dotnet build en esa situación? ¿Qué agrega a las herramientas?

pequeño imbécil 👎

Un intento de ser gracioso, pero probablemente tengas razón.

@poke me disculpo sin reservas.

Sería muy bueno si pudiera captar el concepto entre una respuesta a un extracto citado y un comentario sobre toda la discusión. Supongo que eres capaz de hacer eso, así que la única conclusión es que es deliberado. Si es así, solo le hago saber que es una táctica intelectualmente deshonesta. Espero que lo supieras, pero te doy el beneficio de la duda aquí.

Literalmente, no tengo idea de a qué te refieres.

También creo que definitivamente deberías tomar una pastilla para enfriar.

...

Ataca el argumento, no a la persona.

: InsertRolleyEyeEmoticonHere:

Es curioso, he recopilado pruebas que dicen algo diferente. ¿De dónde sacaste el tuyo?

Está bien, entonces, ¿de dónde vino la cifra del 10% / 90%?

Sí. Entonces estamos de acuerdo. Realmente me gustaría mucho si fuera trivial.

Lo cual no tiene nada que ver con que cambien a msbuild, ya tendrá problemas para cambiar el sistema de compilación actual desde dotnet build .

¿Y dotnet build hará qué exactamente? ¿Shell hacia msbuild?

¿Qué es diferente a dotnet build llamar a msbuild en lugar de dnx o roslyn?

¿Por qué no podemos usar msbuild si queremos usar MSBuild?

¿ Quiere utilizar MSBuild ahora? Nada te detiene, es un paquete nuget en estos días. Vuélvete loco. Sin embargo, me sorprende que lo preguntes, dado lo mucho que odias a msbuild.

¿Cuál es exactamente el propósito de dotnet build en esa situación? ¿Qué agrega a las herramientas?

¿Estamos realmente discutiendo los méritos de dotnet build ? ¿No te gusta dotnet build ? ¿No comprende el propósito de dotnet build ? Eso no parece probable. ¿Qué estás tratando de preguntar?

@neoKushan, por favor, deja de enemistarte con él. esto no es constructivo.

Está bien, entonces, ¿de dónde vino la cifra del 10% / 90%?

Eso vino de mis experiencias personales. Descubrí que alrededor del 90% de las compilaciones que mi equipo y yo hemos creado en los últimos años no han requerido nada más complejo que lo que hace el RC1 dotnet build .

Lo cual no tiene nada que ver con que cambien a msbuild, ya tendrá problemas para cambiar el sistema de compilación actual fuera de dotnet build.

Por favor aclare, no estoy seguro de lo que quiere decir aquí.

¿Quiere utilizar MSBuild ahora? Nada te detiene, es un paquete nuget en estos días. Vuélvete loco. Sin embargo, me sorprende que lo preguntes, dado lo mucho que odias a msbuild.

_suspiro_. Mi pregunta es: ¿por qué dotnet build debería destinarse a MSBuild cuando msbuild hace realmente bien? ¿Por qué dos comandos hacen una sola cosa?

He preguntado esto unas tres veces hasta ahora, y cada vez lo has entendido mal o lo has malinterpretado.

Estoy preguntando acerca de las acciones de dos comandos de línea de comandos diferentes.
Estoy preguntando por qué ambos harán lo mismo
Estoy preguntando, si ambos hacen lo mismo, ¿por qué no tener un comando?
Estoy preguntando qué agrega el segundo comando a la situación si ambos hacen lo mismo
No estoy juzgando la calidad de las herramientas subyacentes en ese contexto, aunque puedo haberlo hecho en otros lugares.
Dicho juicio en otra parte no tiene impacto en la pregunta que se hace, ya que la pregunta que se hace es sobre los comandos de la línea de comando y sus acciones, no sobre las herramientas subyacentes en absoluto.
No estoy tratando de discutir qué más dichas herramientas pueden o no haber hecho en el pasado, simplemente lo que están destinadas a hacer en el futuro.

Perdón por la larga exposición que explica una pregunta de una oración, pero aparentemente es necesaria.

Un artículo sobre InfoQ :
"Microsoft ha llegado a la conclusión de que el experimento project.json ha fallado y volverá a utilizar archivos .csproj". :decepcionado:

Como dije, la percepción importa.

Mi pregunta es: ¿por qué dotnet debería construir shell en MSBuild cuando msbuild ya lo hace realmente bien? ¿Por qué dos comandos hacen una sola cosa?

¿Porque no hacen solo una cosa?

¿Por qué MSBuild debería pasar a csc cuando csc ya hace un buen trabajo construyendo cosas? ¿Por qué dos comandos hacen una sola cosa?

¿Por qué debería dotnet test dirigirse al corredor de pruebas xUnit cuando ya hace un buen trabajo ejecutando pruebas por sí solo? ¿Por qué dos comandos hacen una sola cosa?

¿Por qué debería dotnet restore utilizar NuGet cuando NuGet ya hace un buen trabajo instalando paquetes? ¿Por qué dos comandos hacen una sola cosa?

Entiendes la idea ... (espero: guiño :)

@sandorfr

@neoKushan, por favor, deja de enemistarte con él. esto no es constructivo.

No estoy antagonizando deliberadamente a nadie, estoy deconstruyendo punto por punto el argumento de @shederman , que es exactamente lo que quiere que la gente haga:

Ataca el argumento, no a la persona.

Aunque en este punto, ni siquiera estoy completamente seguro de cuál es el argumento de @shederman , ya que parece que de alguna manera hemos pasado de XML como malo a MSBuild como malo y ahora dotnet build es malo.

Sigamos adelante.

Eso vino de mis experiencias personales.

¿Ésta es su "evidencia"? Que, recuerda, pones en negrita:

Es curioso, he recopilado pruebas que dicen algo diferente. ¿De dónde sacaste el tuyo?

Y ahora es "Experiencia personal". Eso es lo que llamamos evidencia _anecdótica_.

Descubrí que alrededor del 90% de las compilaciones que mi equipo y yo hemos creado en los últimos años no han requerido nada más complejo que lo que hace la compilación RC1 dotnet.

¿Y qué espera que cambie el RC2 dotnet build o el RTM dotnet build o el post-RTM dotnet build a este respecto?

Por favor aclare, no estoy seguro de lo que quiere decir aquí.

Su argumento parece ser (y corregirme si me equivoco) algo como "No es trivial conseguir que dotnet build haga algo diferente a lo que Microsoft programó para hacer". Lo cual estaba bien en los días de DNX porque a todos nos gustaba DNX, pero ahora Microsoft quiere usar MSBuild bajo el capó y no te gusta MSBuild, quieres la opción de cambiar MSbuild por otra cosa, mi punto fue que esto no es nada nuevo, si tuviste algún problema con DNX, entonces tampoco podrías cambiar eso, así que cualquiera que sea tu "problema" con dotnet build , no es nada nuevo y, por lo tanto, no creo que sea relevante a la discusión _actual_ aquí, que es la estructura de project.json entrando. csproj

suspiro. Mi pregunta es: ¿por qué dotnet debería construir shell en MSBuild cuando msbuild ya lo hace realmente bien? ¿Por qué dos comandos hacen una sola cosa?

@khellang ya ha respondido esto, por lo que no quiero repetirme particularmente, pero eso también se debe a que ya he dicho de manera bastante sucinta cuál es la diferencia (odio citarme a mí mismo, pero no creo que realmente hayas leído esto):

dotnet build hace mucho más que "simplemente" llamar al compilador, eche un vistazo a la implementación actual de la CLI de dotnet build . La construcción de un proyecto es solo parte del proceso dotnet build . Eventualmente, _parte_ de ese proceso será llamar msbuild pero ese no es su trabajo, ese es el trabajo de la CLI.

Entonces, nuevamente, al menos por tercera vez: llamar a dotnet build no es sinónimo de llamar a msbuild . No es, como usted dice, "dos comandos que hacen una cosa" y nunca lo fue. Eso nunca estuvo dentro del alcance de toda esta discusión, pero de alguna manera has terminado allí.

La discusión real, la que realmente importa es la estructura de project.json y cómo se fusionará en .csproj. El sistema de compilación subyacente es en gran parte irrelevante si solo desea algo simple porque siempre solo tendrá dotnet build .

Entonces, ¿cómo podemos distinguir entre lo que hace msbuild y lo que hace dotnet build ahora? ¿Cuáles son las diferencias en su funcionamiento? Creo que falta en esta discusión. Probablemente todo el mundo ya lo sepa, pero creo que ponerlo sobre la mesa podría crear algo de claridad.

@khellang Me gusta la forma en que lo expresaste, pero luego, a partir de ahí, puedo configurar lo que hace dotnet test . Puedo poner un corredor de prueba diferente al de xunit en project.json, y dotnet test invocará ese corredor de prueba.

Pero aún así, por lo que he escuchado sobre los próximos cambios, no habrá una capacidad similar con dotnet build . Siempre usará MSBuild para realizar sus compilaciones. ¿Esa comprensión no es correcta?

@neoKushan No me estoy enemistando deliberadamente con nadie, estoy deconstruyendo punto por punto el argumento de @shederman

Bueno, al menos ahora sabemos lo que piensas que estás haciendo. De hecho, lo que estás haciendo es tergiversar, combinar posiciones, malinterpretar deliberadamente las cosas y, en general, ser un poco imbécil. Su tono es combativo y está siendo deliberadamente obtuso. Tanto es así que tuve que intentar dividir las cosas en un pensamiento a la vez. Lo cual, graciosamente, has malinterpretado como un cambio de posición.

@neoKushan Aunque en este punto, ni siquiera estoy completamente seguro de cuál es el argumento de @shederman , ya que parece que de alguna manera hemos pasado de XML como malo a MSBuild como malo y ahora la compilación de dotnet es mala.

XML es malo. MSBuild es malo. Si dotnet build solo usa MSBuild, también es malo. Por favor, intente mantenerse al día. No es tan complicado. Si no estuvieras siendo tan obstinadamente obtuso, lo habrías captado hace mucho tiempo y hubieras podido aportar aportes constructivos.

@neoKushan ¿ Esta es tu "evidencia"? Que, recuerda, pones en negrita:

No, esa fue mi experiencia personal, no la evidencia. Mi evidencia son los 281 encuestados de 383 que creían que el traslado de .NET Core a MSBuild es una mala idea. Y los 85 de los encuestados que creían que MSBuild está fundamentalmente roto. ESA es mi evidencia. ¿Dónde está el tuyo exactamente?

Ya sabes, para respaldar tu afirmación de que "... _todos los desarrolladores de Visual Studio .net tendrían que estar en desacuerdo". [Énfasis añadido]

@neoKushan La discusión real, la que realmente importa es la estructura de project.json y cómo se fusionará en .csproj

De hecho estoy de acuerdo contigo. PERO el telón de fondo es de vital importancia. El plan que MS ha expresado es que MSBuild será el centro del universo de construcción. No me gusta eso, pero sigamos adelante. Dado eso, entonces hay una pregunta simple:

"¿Será MSBuild el sistema de compilación principal para .NET Framework para siempre ?"

Si es así, solo necesitamos un comando msbuild , y no necesitamos un comando dotnet build , es completamente superfluo.

Sin embargo, si aceptamos que en algún momento MSBuild puede no ser el _One True Build System_, entonces estamos en un territorio más interesante. Entonces, tener un dotnet build tiene sentido. PERO entonces es de vital importancia que tengamos en cuenta ese futuro cuando analicemos la fusión de csproj y project.json.

Lo que he intentado (quizás mal) señalar es que una mejor opción (en mi opinión) sería intentar mantener una separación clara entre los archivos de definición de proyecto y los archivos de definición de construcción. Esto nos prepararía mejor para un dotnet build que puede admitir varios motores de compilación. Si, en cambio, trasladamos todo a csproj, entonces nos encerramos en un mundo de MSBuild.

Y sí, entiendo que esta situación de "sólo una construcción verdadera" existía en DNX. Pero no lo interrogué entonces porque me gustaba la construcción que teníamos. Ah, las situaciones en las que nos metemos cuando aceptamos alegremente las injusticias que nos gustan 😉.

Por lo tanto, considere una situación en la que tenemos dotnet build capaces de usar una de varias herramientas de compilación, según la configuración. Al igual que dotnet test puede usar uno de varios corredores de prueba. Ahora, dado un mundo tan imaginario, ahora ¿cómo combinar csproj y project.json? Esa es la discusión que quiero tener.

@rhires Desde un nivel muy alto dotnet build :

1. Recopila los archivos del proyecto.
2. Determina si se cumplen las condiciones previas para una compilación incremental
3. Lee el project.json
4. Determina los marcos de destino
5. Para cada proyecto:
   
   
   
   1. Construir sus dependencias
   
   
   2. Si es incremental, comprueba si se requiere una reconstrucción
   
   
   3. Determina los directorios de salida
   
   
   4. Recopila los archivos de origen
   
   
   5. Determina las opciones de compilación.
   
   
   6. Ejecuta scripts de precompilación
   
   
   7. Ejecuta el compilador con los archivos fuente y las opciones.
   
   
   8. Ejecuta los scripts de postcompilación.
   
   
   9. Salida de informes
   
   

@shederman ¡ Gracias! Desde este punto, ¿qué agregaría / restaría / reemplazaría msbuild a / desde / en este proceso?

Bueno, al menos ahora sabemos lo que crees que estás haciendo. De hecho, lo que estás haciendo es tergiversar, combinar posiciones, malinterpretar deliberadamente las cosas y, en general, ser un poco imbécil. Su tono es combativo y está siendo deliberadamente obtuso. Tanto es así que tuve que intentar dividir las cosas en un pensamiento a la vez. Lo cual, graciosamente, has malinterpretado como un cambio de posición.

Olla -> Hervidor

Has cambiado de posición tantas veces que ni siquiera puedes mantener el ritmo, has discutido literalmente sobre cada aspecto de la cadena de construcción, demostrando que claramente no tienes una comprensión tan buena de cómo funciona todo. juntos como tú piensas, pero yo soy el imbécil porque me atrevo a señalar dónde fracasan tus argumentos. Todavía estoy esperando que responda a la mitad de los puntos que mencioné anteriormente, pero todo lo que debe hacer es pasar a elegir algún otro aspecto del proceso de compilación.

XML es malo. MSBuild es malo. Si dotnet build solo usa MSBuild, también es malo.

Nadie más que _tú_ ha reclamado algo como esto. Nadie. No hay ni el más mínimo indicio de que algo por el estilo vaya a suceder. Te he dicho repetidamente que dotnet build no _sólo_ va a llamar MSBuild , te he dicho que dotnet build y msbuild no son completamente sinónimos de entre sí y que dotnet build hace mucho más que llamar al compilador. Incluso te vinculé al maldito código fuente y otros vinieron y dijeron lo mismo, pero ¿sigues insistiendo en que esto es de alguna manera lo que está pasando?

Por favor, intente mantenerse al día.

¿Qué tal si sigues el ritmo? Por favor, muéstrenos dónde se le ocurrió esta idea de que dotnet build solo llamará a msbuild . ¿Quién te dijo eso? Donde lo leiste?

Mi evidencia son los 281 encuestados de 383 que creían que el traslado de .NET Core a MSBuild es una mala idea. Y los 85 de los encuestados que creían que MSBuild está fundamentalmente roto. ESA es mi evidencia. ¿Dónde está el tuyo exactamente?

Y sacaste el 10% de esas cifras, ¿verdad? Recuerde, este es su reclamo:

Yo diría que el poder y la complejidad de MSBuild son adecuados para el propósito de aproximadamente el 10% de las compilaciones.

Más tarde dijiste:

Es curioso, he recopilado pruebas que dicen algo diferente.

Entonces, ¿dónde está esta evidencia? Me encantaría saber cómo sacaste esa cifra de tu "evidencia".

Ya sabes, para respaldar tu afirmación de que "... todos los desarrolladores de Visual Studio .net tendrían que estar en desacuerdo".

Fácil: https://msdn.microsoft.com/en-us/library/ms171468.aspx

Visual Studio aloja MSBuild para cargar y crear proyectos administrados.

Si usa Visual Studio para crear sus proyectos, usa MSBuild. Incluso cuando se trabaja con .net core hoy en día, incluso con RC1 VS usó MSbuild bajo el capó. Puede que no te guste MSbuild, pero como dije, casi todos los desarrolladores de VS lo usan, se den cuenta o no.

El plan que MS ha expresado es que MSBuild será el centro del universo de construcción.

No estoy de acuerdo con esto. Nunca dijeron que sería el centro, todo lo que dijeron es que algunas partes de project.json terminarían volviendo a .csproj; más allá de esto, no han dicho una palabra sobre hasta qué punto esto cambia el dotnet build proceso.

"¿Será MSBuild el sistema de compilación principal para .NET Framework para siempre?"

Si es así, solo necesitamos un comando msbuild, y no necesitamos un comando dotnet build, es completamente superfluo.

Como se ha dicho muchas veces ahora, dotnet build y msbuild son dos cosas completamente separadas. dotnet build hace más que simplemente llamar a la cadena de herramientas del compilador. El propósito de la compilación de dotnet es mantener el proceso de compilación simple para las personas. Ver de nuevo:

dotnet new
dotnet restore
dotnet build

Incluso si msbuild se convierte en un componente central de la CLI de dotnet, eso no cambia el hecho de que dotnet build es la envoltura limpia y simple de lo que es (y siempre será) un sistema bastante complejo. Demonios, la mitad de la razón por la que existe la CLI dotnet (y DNX antes) es específicamente para alejarse del infierno de argumentos de línea de comandos que es MSBuild. Su argumento es un poco como decir "¿Por qué necesitamos un comando npm install cuando solo puedo curl el paquete?". Claro, puede hacerlo todo manualmente si realmente lo desea, pero no obtiene casi nada de ello. Entonces, ¿qué pasa si dotnet build usa msbuild debajo del capó? Es casi seguro que nunca lo verá o necesitará saberlo.

No puede comparar su antigua experiencia con MSBuild, es completamente diferente. Todos (aparentemente) hemos sido quemados por ese porque estamos acostumbrados a abrir VS, crear un proyecto y hacer que se compile, pero luego, cuando vas a tener ese mismo proyecto compilado en un servidor de compilación, de repente se queja de una mierda. eso debería _simplemente funcionar_. Probablemente una de las mejores cosas que hizo Microsoft con TFS 2015 fue crear una definición de compilación que se vincule con _Visual Studio_ en lugar de _MSBuild_ porque está de vuelta "simplemente funcionando". Eso es exactamente lo que es esta cadena de herramientas de compilación: dotnet build no está destinado a reemplazar todo su sistema de compilación, solo se ocupa de construir sus proyectos, incluso si usa MSBuild bajo el capó. Si desea usar algo como TeamCity o Jenkins, dotnet build es todo lo que tiene que decirles que llamen y dotnet hace el resto. _Cómo_ eso no te preocupa.

Lo único, y lo digo completamente, lo único que realmente cambia para usted es el archivo project.json / csproj. Eso es_. Es por eso que toda esta discusión sobre lo que dotnet build realmente hace y para qué MSBuild es bueno y malo es absolutamente _inútil_.

@neoKushan solo detente ...

@neoKushan solo detente ...

A una parte de mí le gusta imaginarme al equipo de ASP.NET cancelando deliberadamente el standup porque estaban disfrutando del espectáculo, y dar respuestas acabaría con todo. :sonrisa:

Desde mi posición (ahora firmemente) agnóstica, ambos lados han parecido ser deliberadamente obtusos con respecto a los puntos del otro desde hace algún tiempo. Está logrando establecer mi imagen mental de la comunidad de .NET Core como no constructiva y peor. Hablar de percepción ...

La mayoría de las cosas que no son de NuGet se fusionarán con csproj. ¿Qué pasará con las cosas de NuGet si no hay project.json (nuget.json?)?

proporcionar una forma para que los usuarios administren sus dependencias de la manera que deseen, y tal vez proporcionar un dotnet nuget de forma predeterminada, ya que NuGet está bien establecido en la comunidad .net.

pero no acople todas las cosas del núcleo de dotnet con esa única forma de administrar las dependencias ( dotnet restore no debería ser igual a dotnet nuget restore ), para muchas personas nuget es solo un repositorio de paquetes pero no un administrador de dependencias, las personas tienen otras opciones que pueden encontrar más productivas / adecuadas para el caso de uso del "administrador de dependencias".

¿Mantendremos IntelliSense para la gestión de dependencias? Esta es básicamente una de las mejores funciones de demostración que tenemos para project.json.

puede reutilizar la lógica, no veo esto como un gran problema, por ejemplo, voy a nuget.org y hago una búsqueda de un paquete y copio la identificación de la URL, es eficiente.

Es posible que también desee proporcionar la terminación de shell, lo que le comprará mucha admiración por parte de las personas que usan bash o zsh :

dotnet nuget add S[tab] proporciona una lista de finalización para los identificadores de proyectos que comienzan con S

tener intellisense en los archivos msbuild * proj también debería ser factible si desea hornear una etiqueta <NuGet> allí, pero lo mismo, no empareje con fuerza a todo el ecosistema, es decir, <Package>NuGetPackageId</Package> shouldn ' t equivale a <NuGet>NuGetPackageId</NuGet> O debe haber una forma muy simple (y extremadamente bien documentada y respaldada) de anular esto.

El complemento Paket Visual Studio tiene autocompletado en nuget, funciona pero es un poco lento de todos modos porque supongo que lleva algo de tiempo devolver la respuesta de nuget.org.

¿Mantenemos el formato JSON para la gestión de dependencias? XML es horrible para ese tipo de cosas (ver Maven). JSON es sin duda más simple para representar esas dependencias.

Si está buscando ideas para el formato, puede mirar paket.dependencies , de lo contrario, no creo que importe mucho, editar el project.json fue más o menos tan agradable como editar packages.config en términos de tratar con NuGet, haga lo que sea conveniente para los usuarios que eligen NuGet como administrador de dependencia de paquetes (que no es el 100% de los usuarios y no es necesario)

Como nota al margen, si todavía necesita un archivo lock , ¿podría hacerlo legible por el usuario, algo que se verifique en el repositorio y que sea fácil de diferenciar?

@rhires A partir de este punto, ¿qué agregaría / restaría / reemplazaría msbuild a / de / en este proceso?

Bueno, eso depende de cómo lo integren. Si hacen un "bloqueo duro", integrando msbuild profundamente en dotnet build, que la información pública parece indicar que es su enfoque preferido, entonces sería reemplazado en su totalidad por msbuild.

Sin embargo, si hacen que dotnet build configurable, espero que funcione de la siguiente manera:

1. Recopila los archivos del proyecto.
2. Lee el project.json
3. Determina los marcos de destino
4. Determine la herramienta de construcción que utilizará
5. Shell a la herramienta de construcción
6. Salida de informes

@neoKushan Es por eso que toda esta discusión sobre lo que realmente hace la compilación dotnet y para qué MSBuild es bueno y malo es absolutamente inútil.

👍

Lo que quiero _discutir_ es cómo deberían verse project.json y csproj en un mundo donde dotnet build puede desembolsar a MSBuild como una de las _muchas herramientas de compilación posibles_. ¿Eso está bien? ¿Podemos hablar de lo que estaría en project.json vs lo que estaría en csproj, dado eso?

Porque si _podemos_ discutir eso, creo que este hilo puede llegar a ser constructivo.

@jmm Está logrando establecer mi imagen mental de la comunidad de .NET Core como no constructiva y peor

Lo siento por eso. Sin embargo, si tiene tiempo, le sugiero que lea algunos de los archivos de chat de otros grandes proyectos de código abierto.

Las discusiones son en realidad un signo de una comunidad saludable, como en la vida. Cuando todos siguen ciegamente a un grupo de líderes, bueno, las cosas normalmente no son tan buenas. Las decisiones, las pruebas y la toma de decisiones deben estar abiertas a interrogatorio.

@shederman En interés de continuar una discusión productiva, también me gustaría trazar una línea para discutir las implicaciones de los cambios propuestos.

Creo que la discusión principal aquí debería estar en el diseño y formato del "nuevo" .csproj y lo que sucede con project.json (O para ser específico, la estructura del "proyecto" como un todo). No creo que el sistema de compilación, ya sea msbuild o no, cómo funciona la compilación de dotnet, etc., esté dentro del alcance de este problema. Eso no quiere decir que las discusiones sobre eso no sean bienvenidas o no sean válidas, solo que no pertenecen a este tema _específico_, sino que deberían ser temas separados. Como puede atestiguar cualquier desarrollador experimentado, es muy frustrante cuando un informe de error contiene varios errores separados y, por lo general, lo primero que haría es dividirlos en varios problemas para realizar un seguimiento; creo que eso es realmente lo que falta aquí.

Desde mi propia perspectiva _personal_, no me importa cuál es el sistema de compilación o cómo funciona. No quiero decir que suene ignorante o despectivo para aquellos que lo hacen, quiero decir que desde la perspectiva del desarrollador, solo quiero saber que "dotnet build" escupe mi ensamblaje siempre que la estructura del proyecto sea correcta, hasta ahora en lo que a mí respecta, dotnet build -> Proyecto ->-> Montaje. Lo único que realmente me importa, y cuál debería ser el alcance de esta discusión (y creo que finalmente estamos de acuerdo aquí) es cómo se ve ese proyecto y qué significa para mi flujo de trabajo diario.

No quiero lidiar con el infierno de fusiones solo porque agregué un archivo .cs, ni quiero lidiar con un archivo XML de mil líneas solo porque algún sistema que _no me importa_ depende de él, yo no ' No creo que ninguno de nosotros lo haga y eso ha sido un error del desarrollo de VS durante años. Tuvimos un rayo de esperanza con el formato project.json tal como está hoy porque era _mucho mejor_ que el anterior, así que entiendo completamente y entiendo por qué los ánimos se deshilacharon tan rápido ante la mera insinuación de que volveríamos a los "malos viejos tiempos", pero al mismo tiempo vale la pena decir que no debemos engañarnos a nosotros mismos: project.json hoy no es de ninguna manera _perfecto_, tiene su propio conjunto de problemas y, si bien pueden ser menores en comparación con el problemas del "antiguo" csproj, vale la pena ser objetivo y discutir dónde se podrían mejorar las cosas y qué se podría mejorar.

Definitivamente hay una posibilidad _mejor de ambos mundos_.

Creo que la discusión principal aquí debería estar en el diseño y formato del "nuevo" .csproj y lo que sucede con project.json (O para ser específico, la estructura del "proyecto" como un todo).

Ya sabes, se ha mencionado varias veces en este hilo, pero pensé que lo mencionaría de nuevo, solo para compartir mi propio "ajá personal" esta mañana, pero hay un esfuerzo completamente diferente en marcha con el sistema de proyectos basado en Roslyn. - o para ser más exactos de su archivo Léame el Sistema Central de Proyectos (CPS) . Examinar su documentación parece ser más un esfuerzo de definición de proyecto que un proceso. ¿Quizás aquí es donde se está consolidando toda la magia entre .json y .csproj? ¿Y luego MSBuild será relegado como un punto final de proceso? No sería agradable. :sonrisa:

De todos modos, comencé / miré ese repositorio para comenzar a recibir actualizaciones sobre lo que está sucediendo allí. : +1:

(También me estoy preguntando a medias si deberíamos mover esta discusión a un nuevo tema allí).

@neoKushan Definitivamente, el hecho de que haya msbuild involucrado no es problemático en sí mismo. Y creo que hay un camino a seguir que nos permitiría mantener formatos de archivo simples legibles / editables por humanos mientras aprovechamos el poder de msbuild.

Lo que me preocupa son argumentos como "msbuild está probado en batalla", msbuild normal lo es, pero el xplat actual no parece serlo. Cuando analizamos los problemas en el repositorio de github relacionado, todavía no ha llegado. Además, el equipo de msbuild ya dijo que admitir un formato de serialización nuevo / mejorado no será un objetivo para msbuild sino más bien para un nuevo sistema de compilación (que no sucederá pronto).

También me preocupa cuando la gente asume que lo que hacemos es simplemente agregar eliminando dependencias. Tal vez sea lo que hacen porque solo están haciendo aplicaciones de 'hola mundos'. Pero otras opciones como buildOptions y anulaciones por apodo son extremadamente poderosas y prácticas. Sin mencionar que la experiencia actual del editor basado en esquemas json es simplemente increíble.

Una ruta podría ser tener una tarea msbuild que cargaría project.json como alternativa. Luego, deje que el desarrollador elija en la configuración del proyecto si desea habilitar project.json, lo que agregaría esa tarea al csproj.

@ Mike-EEE Sí, hay esperanza :)

Estoy bastante seguro de que la tendencia actual es hacer que project.json se convierta en nuget.json, lo que con suerte resolvería el problema de dependencia y dejaría intacta la mayor parte de la funcionalidad de project.json existente.

Lo único que no puedo entender es cómo afecta esto a la orientación múltiple, ¿tendrían que csproj y nuget.json ser conscientes y comprender a qué se dirigen cada uno? ¿Terminamos con un csproj para cada objetivo (¡qué asco!), ¿O pueden extender .csproj lo suficiente para dar cuenta de ello?

project.json se convierte en nuget.json

Solo curiosidad aquí ... ¿Dónde está sucediendo _esta_ conversación? Me uní al equipo nuget antes por encerrarme con un formato particular. Con respecto a project.json, dijeron que era una preocupación de las herramientas de Visual Studio y algo que no podían abordar. Ahora parece que la dinámica ha cambiado y se han copiado / pegado más problemas del mismo tipo. : Lengua_salida_atascada:

Para aclarar mi preocupación, es que ahora estamos mezclando JSON y XML, lo que produce ineficiencia como mínimo.

Solo curiosidad aquí ... ¿Dónde está sucediendo esta conversación?

Bueno, originalmente se dijo aquí: https://blogs.msdn.microsoft.com/webdev/2016/05/11/notes-from-the-asp-net-community-standup-may-10-2016/

Es posible que el archivo project.json permanezca y contenga todas las referencias del paquete para NuGet y se le cambie el nombre a nuget.json.

Y creo que de esto se trata realmente la discusión aquí, ¿cuánto sacas de project.json y pones en un .csproj? En mis proyectos, la mayoría de project.json han sido referencias de paquetes, especialmente si me dirijo a múltiples marcos. Lo anterior sugiere que todo esto permanecería y solo se eliminarían los "otros" bits. En mi experiencia (de nuevo: Personal), estos "otros" bits realmente no cambian mucho a lo largo de la vida de un proyecto, por lo que incluso si está en XML, no es mucho XML y debería ser bastante estático ... uno espera .

Estoy de acuerdo en que mezclar y combinar XML y JSON para diferentes configuraciones huele un poco, pero estoy algo sesgado en contra de JSON, ya que no soy un gran fanático de cómo se usa. Sin embargo, esa es definitivamente una preferencia personal.

Bueno, originalmente se dijo aquí ...

Ah si ... ¡por supuesto! está bien. Solo asegurándome. Con suerte, mañana será el día en que finalmente tengamos algo de claridad (¡para bien o para mal!) Sobre esto.

Estoy de acuerdo en que mezclar y combinar XML y JSON para diferentes configuraciones huele un poco

Realmente me alegro de no ser el único que ve esto y se siente de esta manera. :) Parecía solitario allí por un tiempo cuando por primera vez luché contra el dolor de ver a .JSON arrastrándose en los proyectos. Totalmente tiene sentido desde un fondo de web-AppDev, pero el AppDev nativa no vería debilitada, y viceversa cuando se trata de XML.

Jaja ... hablando de eso, escribir lo anterior me hizo sacar los viejos archivos. Aquí estoy yo en 2014 defendiendo (¡sí, lo adivinaste!) Xaml en lugar de JSON jajaja ¡oh, mira lo joven y completamente ingenuo que era! ¡Tan lindo y sin pretensiones! Chico, tenía el mundo para aprender. : stick_out_tongue: Pero, diré que ha habido ALGUNOS progresos. Después de todo, nos deshicimos de ese .ini utilizado para la configuración del servidor web . :sonrisa:

@neoKushan Definitivamente hay una posibilidad de lo mejor de ambos mundos.

👯 👯 👯

@neoKushan Estoy bastante seguro de que la inclinación actual es hacer que project.json se convierta en nuget.json ... Lo único que no puedo entender es cómo afecta esto a la orientación múltiple, ¿tendrían que ser conscientes csproj y nuget.json? de y comprende a qué se dirigen cada uno?

Usando el esquema project.json como punto de partida, desde mi perspectiva, los siguientes elementos probablemente _no_ deberían estar en el archivo de definición de compilación:

• Lista de archivos fuente
• Dependencias del proyecto
• Marcos de destino
• Comandos del proyecto (por ejemplo, web, prueba, etc.)
• Webroot
• Metadatos
• Versión de idioma

Lo siguiente que no creo que debería estar en el archivo de definición de compilación, pero sería _meh_ al respecto si lo fuera:

• Definiciones de configuración
• Guiones, pre y post

Lo siguiente probablemente _debería_ estar en el archivo de definición de compilación:

• Opciones de compilación (excluyendo la versión de idioma)

Lo anterior es solo para provocar discusión. Feliz de debatir cualquier punto individual. Sugiera ignorar cómo se llaman los archivos y qué formato tienen por ahora.

@shederman ¿Necesitamos aclarar lo que quiere decir con "definición de compilación"? Quizás mi terminología está apagada, pero no llamaría al project.json actual un archivo _build definition_ sino más bien un _project definition_ file (y lo mismo se aplicaría al nuevo archivo csproj). Posiblemente semántica, pero para mí una definición de compilación sugiere que define _cómo se construyen las cosas_, mientras que una definición de proyecto define lo que constituye un proyecto y deja los pasos de compilación a otra cosa.

_Este es mi proyecto, consta de estos elementos y tiene estas dependencias. Cómo lo construyes no es asunto mío.

Gran parte del proyecto se puede determinar simplemente mediante una convención, como la forma en que el nombre del ensamblado proviene de la carpeta de nivel superior. Siguiendo esta línea de pensamiento, _nuget.json_ sería cualquier cosa que ver con nuget, por lo que los paquetes / dependencias entrarían allí y creo que todos estamos contentos con eso.

Lo que no puedo decidir del todo son los marcos de destino. Si Nuget.json solo se preocupa por la resolución de dependencias, entonces, aunque podría tener alguna separación para las referencias cuando se dirige a diferentes marcos, no estoy del todo seguro de que deba ser el que decida qué marcos están realmente dirigidos, eso parece algo más para el _proyecto definición_ (lo que sea que termine siendo).

Por otra parte, nuget es más que solo referencias de paquetes, también contiene el paquete _definition_ y la versión para cuando su biblioteca _se convierte_ en un paquete nuget. Parece un poco como si nuget.json estuviera haciendo al menos dos cosas diferentes y eso está empezando a oler un poco. Quizás (solo escupiendo aquí), el csproj definiría los detalles del paquete, los marcos de destino, etc. y cada marco de destino podría apuntar a un archivo .json, que es básicamente los paquetes nuget. En otras palabras, en lugar de un nuget.json, tendría un archivo .json separado para cada marco. Puede que sea una idea terrible, no la he pensado especialmente.

https://blogs.msdn.microsoft.com/dotnet/2016/05/23/changes-to-project-json/ :

Teníamos dos opciones. Uno fue mover todos los proyectos .NET para usar project.json. Esto requeriría que hagamos un trabajo de herramientas que afecte a todos los tipos de proyectos en Visual Studio, Xamarin y nuestros socios como Unity. Tendríamos que expandir project.json para admitir todos los escenarios de compilación requeridos por cada uno de estos tipos de proyectos y proporcionar una historia de migración. Otra opción fue construir puentes para que un proyecto .xproj pueda hacer referencia a un proyecto .csproj y un proyecto .csproj pueda hacer referencia a un proyecto .xproj en Visual Studio y Xamarin Studio. El puente también presenta desafíos, por ejemplo, cuando un cliente crea un proyecto, ahora tendría que elegir un .xproj o un .csproj, lo que simplemente agrega más opciones y complejidad.

Y

Después de analizar nuestras opciones, resultó evidente que sería más fácil mover proyectos .NET Core a .csproj / MSBuild, por lo que todos los proyectos .NET usan las mismas herramientas y sistema de compilación.

Planeamos mejorar .csproj para admitir la funcionalidad faltante:

• Sin lista de archivos en el sistema de proyectos
• Herramienta CLI para realizar cualquier operación en el archivo del proyecto, para la mayoría de los escenarios no editaría el archivo
• Cree paquetes directamente desde el proyecto
• Orientación múltiple

Y debido a que todo .NET usa las mismas herramientas, podemos considerar la mejora de MSBuild. Solicitaremos comentarios de los clientes y la comunidad sobre la compatibilidad con JSON en lugar de XML, para que nuestras herramientas no generen archivos demasiado detallados y más. Y debido a que todo usa las mismas herramientas, estas mejoras podrían funcionar en todos los proyectos .NET.

https://blogs.msdn.microsoft.com/dotnet/2016/05/23/changes-to-project-json/#comment -71485:

Suponiendo que .csproj todavía significa Proyecto C #, por supuesto, habrá otros objetivos para proyectos que no sean C #, ¿correcto? [Ben]

Si. [Scott H]

Tengo un poco de miedo de que .net se quede atascado con un sistema de compilación complejo-heredado-justForTooling como msbuild, ¿tal vez deberíamos comenzar con él para poner en funcionamiento dotNetCore y luego planificar un nuevo sistema de compilación moderno?
Para dar esperanza a todos y hacer las cosas sin prisas de envío .netcore.

No necesito editar archivos msbuild con frecuencia, pero cuando lo necesito es muy difícil, el enfoque declarativo te hace perder en el flujo, traigo mi ejemplo, nadie parece ser capaz de resolver un problema simple como este https: // github .com / madskristensen / BundlerMinifier / issues / 89
Si después de 6 meses nadie pudo ejecutar una tarea (dos tareas diferentes cada una sin saber la otra) tras otra sin hackings sucios o de forma aditiva, tal vez haya algo que arreglar allí.

Gracias

Herramienta CLI para realizar cualquier operación en el archivo del proyecto, para la mayoría de los escenarios no editaría el archivo

: -1:

Estoy a favor de las herramientas CLI para ayudarlo a hacer su trabajo, pero si tengo que usar una herramienta CLI para administrar referencias y paquetes, me enojaré. Install-package es genial, pero poder escribir la mitad del nombre del paquete y hacer que aparezca una lista de posibilidades, con todas sus versiones, fue increíble.

Las herramientas cli son excelentes para la automatización, pero son una forma deficiente de realizar tareas, excepto las básicas como npm install o dotnet restore . Si tenemos que aprender cosas como dotnet buildoptions define add --framework net451 SOME_DEFINE definitivamente apesta. Esta es una gran pérdida.

Una buena historia de desarrollo es:

• Archivos de construcción y proyecto fácilmente editables
• Sistema de construcción configurable
• Herramientas cli simples, bien diseñadas y completas
• Gran interfaz gráfica de usuario, herramientas IDE

Hacer que uno de esos pobres (que en realidad era genial antes) para que otro sea aceptable es simplemente estúpido.

El argumento de la unidad y xamarin es bastante malo en realidad. No creo que se trasladen al núcleo de .net tan pronto, y retroceder para su conveniencia es poco convincente cuando se diseña para el futuro de .net.

Y debido a que todo .NET usa las mismas herramientas, podemos considerar la mejora de MSBuild

No se puede mejorar MSBuild antes de que nos veamos obligados a hacerlo ...

Este artículo no es realmente la publicación de blog que estábamos esperando y confirma que .net core se está equivocando allí.

Las herramientas cli son excelentes para la automatización, pero son una forma deficiente de realizar tareas, excepto las básicas como npm install o dotnet restore.

Una vez más, siento que este problema es un choque de culturas / preferencias / filosofía. En algún momento, CLI se convirtió en una buena idea para reemplazar la GUI, cuando realmente necesita ambas, ya que encontrará que los desarrolladores (una vez más) tienen su preferencia de enfoque. Ciertamente se requiere algo de innovación en esta área, ya que parece que constantemente es un problema: se crea CLI, pero no se crea GUI y viceversa.

Para mí, parece que se necesita una especie de marco para crear la API y luego las versiones CLI y GUI se crean automáticamente para usted.

Podríamos llamarlo ... ¡CLIGUIAPI! : +1:: +1:: +1: #problemsolved

este problema es un choque de culturas / preferencias / filosofía

Definitivamente, y este es uno que no puede resolver excepto por abordar cada enfoque con el mejor enfoque posible. node.js y no soy el mayor fan de esta pila, hice un gran trabajo al tener la gran herramienta cli npm y package.json. La parte de la interfaz gráfica de usuario está dirigida por varios proveedores (webstorm, vs code, visual studio). Los sistemas de construcción sofisticados como gulp son cien por ciento opcionales.

tal vez sea una minoría en esto y tal vez no, pero aunque me gusta project.json, las razones explicadas aquí https://blogs.msdn.microsoft.com/dotnet/2016/05/23/changes-to-project -json / tiene mucho sentido para mí. Estoy bastante seguro de que terminaremos con una buena experiencia, así que realmente no estoy preocupado por esto y de ninguna manera disminuye mi entusiasmo por estos nuevos marcos. La gente parece muy rápida para salir de las horquillas y actuar como si fuera el fin del mundo incluso antes de ver cuál será la experiencia final.

Dejé de leer hace un tiempo, pero cerraré este problema tan pronto como tengamos una respuesta definitiva sobre project.json .

¿Qué tal mantener project.json y .csproj, donde .csproj se genera mediante el comando dotnet restore y no se sincroniza en el control de versiones de forma predeterminada? La diferencia será que, en lugar de dotnet restore generar “project.lock.json” (y hacer otras cosas), generará (o actualizará) el archivo “.csproj”. Incluso tanto "project.lock.json" como ".csproj" pueden permanecer, ya que ambos se generan automáticamente. Las banderas se pueden usar en dotnet restore para generar .csproj. En el anuncio, Microsoft ya está diciendo: "Herramienta CLI para realizar cualquier operación en el archivo del proyecto, para la mayoría de los escenarios no editaría el archivo". En mi humilde opinión, dotnet restore es más adecuado para ser ESA herramienta CLI, que tomará project.json como entrada. Las ventajas serán-

• Ambos formatos de project.json y .csproj pueden permanecer sin cambios. Eso significa que el nuevo .csproj generado será compatible con versiones anteriores de Visual Studio y otras herramientas. dotnet restore puede insertar una lista explícita de "incluir" de archivos de proyecto en el archivo .csproj.
• Como .csproj se genera automáticamente y no está en control de versiones, los desarrolladores no tienen que lidiar con la edición manual y la fusión de .csproj.

Si no.

Clausura. Se ha dicho todo lo que se podía decir.

Si quieres averiguar cómo se debe hacer y estar en el equipo de diseño que habla de ello ... hazlo .

De lo contrario, es espacio desperdiciado y especialmente ... está llenando bandejas de entrada.

@MaximRouiller espera que recopile los comentarios que se centren en responder a sus preguntas iniciales a pesar de la cantidad de ruido.

publicado ayer:

https://blogs.msdn.microsoft.com/dotnet/2016/05/23/changes-to-project-json/

@neoKushan ¿Necesitamos aclarar lo que quiere decir con "definición de compilación"? Quizás mi terminología está apagada, pero no llamaría al project.json actual un archivo de definición de compilación sino más bien un archivo de definición de proyecto (y lo mismo se aplicaría al nuevo archivo csproj). Posiblemente semántica, pero para mí una definición de compilación sugiere que define cómo se construyen las cosas, mientras que una definición de proyecto define lo que constituye un proyecto y deja los pasos de compilación a otra cosa.

Bastante acertado en mi pensamiento. La definición del proyecto sería una descripción puramente declarativa de lo que es el proyecto. Metadatos, versiones, especificaciones de archivos, etc. La definición de compilación serían los pasos que se realizan para convertir el proyecto en código ejecutable. Es casi seguro que la definición de compilación necesitaría algo bastante rico para expresarla, mi favorito es el código.

Pero, todo parece discutible: @MaximRouiller y MS han cerrado todo. Sus comentarios han sido ignorados y archivados, gracias por llamar.

En general, todo el asunto csproj -> project.json -> csproj fue un conjunto de malas decisiones que volverán a acechar a MS en la adopción de .NET en mi humilde opinión. La tendencia de los desarrolladores a abandonar .NET por pastos más verdes continuará sin cesar.

Muy triste.

@shederman No existe una correlación entre un índice de Tiobe en declive para C # y la decisión de volver a cambiar a csproj. Además, un índice de Tiobe en declive no es una indicación de la salud en declive del ecosistema de C #. Más idiomas que ingresan al mercado dificultan que un idioma mantenga una gran participación en el mercado.

No tengo claro el impacto en su conjunto, pero quisiera señalar que debería haber una separación de la evaluación de las preocupaciones aquí. Si csproj significa que solo porque estoy agregando un archivo, mis compañeros de equipo están preocupados por otros impactos relacionados con el proceso de compilación, entonces estamos perdiendo el barco.

csproj es algo que tolero, no prefiero.

@jerometerry No estaba diciendo que esto en sí mismo causará un declive. Pero muchos de los cambios innovadores en .NET Core tenían como objetivo detener el declive y las pérdidas de AWS. Estos cambios se están eliminando lentamente uno por uno y, por lo tanto, es cada vez más improbable que .NET Core atraiga a los desarrolladores a la plataforma.

Además, la mala toma de decisiones, que se remonta a la decisión de introducir project.json hasta el día de hoy, no augura nada bueno.

Si los EM están decididos a centrarse en el pasado, no deberían sorprenderse cuando salgan perdiendo en el futuro. Es poco probable que el pensamiento que te metió en un problema te saque de él.

Más idiomas que ingresan al mercado dificultan que un idioma mantenga una gran participación en el mercado.

Es cierto, pero en mi experiencia, más daño del necesario en .NET es causado por fuego amigo.

Por cierto ... ¿hubo incluso una pelea ayer? Me registré en live.asp.net pero la cuenta regresiva simplemente se reinició, sin video / feed ni nada ...

@ Mike-EEE Se enteraron de que venías: atascado_out_tongue_winking_eye:

Frustrante que hicieron esto. Escribí en un blog al respecto: http://www.brettmorrison.com/microsofts-little-decision-is-a-big-mistake

Desde el stand de hoy: https://youtu.be/YJsQ3tnS7Ew?t=38m45s

Él se dirige específicamente a project.json aquí: https://youtu.be/YJsQ3tnS7Ew?t=26m12s

Aunque el formato project.json es mucho más simple de editar (a menos que esté en la etapa de desarrollo de .NET de ser un mono de conjunto de datos de arrastrar y soltar), el mayor problema para mí es que nadie se molesta en actualizar sus bibliotecas al formato. netcore. Hasta ahora he logrado que funcione una rama de Restsharp, pero esta usa el formato project.json. JSON.NET, Structuremap, NUnit, etc., etc., tienen ramas DNX obsoletas donde parece que los desarrolladores abandonaron la esperanza.

Por lo tanto, es un poco extraño llamar a .NET Core RC1 / 2 un candidato de lanzamiento cuando se elimina el formato del proyecto de la herramienta de línea de comandos dotnet . Eso para mí sigue siendo un software beta o incluso alfa, ya que es experimental.

Mi principal motivación para pasar a vNext es utilizar un alojamiento Linux barato y Docker. Sería aconsejable una herramienta de migración de proyectos lo antes posible, ya que la mayoría de las personas estarán completamente discapacitadas por sus bibliotecas a través de las referencias nuget que faltan en las versiones de .NET Core.

@yetanotherchris dnx era un concepto en rc1, cambió a dotnet cli en rc2, por lo que la mayoría de los proyectos o ramas de dnx estarían obsoletos en este momento

project.json todavía está aquí y es necesario para rc2, la discusión sobre esto desaparecerá en el futuro después de RTM

json.net, también conocido como newtonsoft.json, funciona y es utilizado por el marco en sí, también lo uso en mis proyectos
nunit no es compatible, todo el mundo usa xunit afaik
Structuremap tiene una biblioteca compatible con rc2

todavía hay muchas cosas de terceros que aún no se han portado a rc2, pero Microsoft no controla el tiempo de otros proyectos y cuándo crearán bibliotecas compatibles

@yetanotherchris Si usa importaciones en su project.json, puede especificar los antiguos apodos no estándar de red y los usará:

"frameworks": {
  "netcoreapp1.0": {
    "imports": [
      "dotnet5.6",
      "dnxcore50",
      "portable-net45+win8"
    ]
  }

Probablemente sea por esta razón que no muchas personas se han molestado en actualizar sus bibliotecas todavía, no hay necesidad de alcanzar otro objetivo en movimiento antes del RTM real.

@joeaudette Estaba hablando del nombre de la rama (DNX), no de la herramienta de línea de comandos dotnet . Mucha gente usa NUnit, es más o menos el conjunto de pruebas de facto fuera de MsTest. No estoy seguro de dónde está encontrando los paquetes JSON.NET o Structuremap, hay una versión no oficial de Structuremap llamada DNX y una rama de Newtonsoft aquí y una versión beta de .NET Standard 1.0 en nuget.org (el estándar .net ahora es redundante por lo que sé).

@neoKushan gracias, lo investigaré.

Creo que mi punto principal fue que es un poco tonto llamarlo candidato de lanzamiento, ya que cambiará por completo para la versión final. Tal vez en un mes tengamos una gran actividad ahora que los sistemas de compilación no son completamente diferentes de los antiguos y nuevos, aunque como alguien que es principalmente un desarrollador web, preferiría project.json .

@yetanotherchris

(El estándar .net ahora es redundante hasta donde yo sé).

¿Qué te hace decir eso? Netstandard no desaparecerá con el cambio de proyecto, está aquí para quedarse. Podrá apuntar a estándares de red en sus futuros archivos csproj. Netstandard es absolutamente esencial. Una de las principales razones por las que están abandonando project.json es para unificar todo el ecosistema .net y eso es lo que netstandard también está aportando.

Creo que mi punto principal fue que es un poco tonto llamarlo candidato de lanzamiento, ya que cambiará por completo para la versión final.

Estoy de acuerdo con esto hasta cierto punto, aunque no creo que esté cambiando tanto como la gente piensa. Para empezar, project.json todavía estará aquí para el RTM, todos los cambios ocurrirán después de eso. Entonces podrías preguntar por qué llamarlo "Final" si va a cambiar y tal vez haya un punto ahí, pero en última instancia, todo tu código y bibliotecas y todo lo que no está cambiando, es solo la definición del proyecto. Ese no es un cambio tan grande como uno podría pensar inicialmente, aunque definitivamente habrá algo de diversión con la migración.

@yetanotherchris , debe recordar que rc2 es una vista previa y, por lo tanto, debe buscar paquetes de vista previa de terceros también.
https://www.nuget.org/packages/Newtonsoft.Json/9.0.1-beta1
https://www.nuget.org/packages/StructureMap.Dnx/0.5.1-rc2-final

No sé si NUnit será compatible más adelante, pero por ahora en los proyectos de .NET Core y ASP.NET Core, la gente está usando xunit
https://xunit.github.io/docs/getting-started-dotnet-core.html

@yetanotherchris Creo que todos podemos estar de acuerdo en que rc1 debería haber sido etiquetado como beta9, rc2 es el primer lanzamiento de calidad rc real
project.json y las herramientas no forman parte del marco en sí, las herramientas seguirán siendo una vista previa y estarán sujetas a cambios por un tiempo, incluso cuando el marco sea RTM

Ni siquiera me sorprendería si lo devolviéramos, tal vez conservemos un project.json, y solo funciona en escenarios limitados. Si eso es lo que la gente quiere, consideraremos esa idea.

Scott Hunter, discurso principal del día 1 de dotnetConf 2016 12m24s

¿Alguien sabe si Mr. Hunter está en GitHub? ¿Y monitorear la charla en los foros de productos? Por lo que parece, se está perdiendo la retroalimentación aquí.

Como administrador del programa para .NET y Visual Studio, dudo que @coolcsh honestamente tenga tiempo libre.

Me horrorizaría mucho si no estuviera al tanto de los comentarios que se le han dado. Quizás no todos los detalles, pero ciertamente ha habido un retroceso significativo.

Esta es su oportunidad para todos:
https://blogs.msdn.microsoft.com/webdev/2016/06/08/notes-from-the-asp-net-community-standup-june-2-2016/

Pongo un dólar en el frasco de propinas, por así decirlo. : Lengua_salida_atascada:

Tugberkugurlu pudo haber estado en algo con el comentario "de repente, los desarrolladores empresariales de materia oscura comenzaron a dar su opinión a puerta cerrada". Otra forma en que podría decirse es que "nuestros clientes empresariales plantearon algunas preocupaciones válidas sobre la compatibilidad y su inversión actual en nuestros productos". Si bien la 'comunidad' parece descontenta de no tener la mayor parte de la voz en, bueno, todo, los clientes empresariales tienen una vara bastante grande: pagan mucho dinero por el acceso a plataformas, herramientas y soporte. Sus preocupaciones no van a ser ignoradas, ni deben ser ignoradas. Al final, lo que MS parece apuntar es permitir que el número máximo de desarrolladores creen lo que quieren construir, fácilmente, y también quieren intentar habilitar la interoperabilidad y el uso compartido en casi todos los dominios definibles. Prometen hacer que csproj sea mucho más fácil de trabajar y mucho más capaz. Entonces, ahora, están listos para cumplir con eso.

Como he dicho muchas veces, soy un desarrollador empresarial en un banco importante, un cliente empresarial. No nos consultaron sobre estos cambios. Entonces, ¿Quiénes eran exactamente los "desarrolladores de empresas de materia oscura"? Aparentemente, esa información es de alto secreto. 007 cosas de nivel.

Está muy bien afirmar que los clientes empresariales tienen un gran garrote, pero aparentemente solo ALGUNOS de ellos pueden hacerlo. ¿Cuáles? ¿En base a qué criterios? ¿Cómo entramos en esa lista de privilegiados? ¿Qué nivel de socio es? ¿Qué gasto anual? Las mentes inquisitivas quieren saber cuánto tenemos que pagar EXACTAMENTE a la EM antes de que realmente escuchen nuestras opiniones.

@shederman, ¿ es usted un desarrollador móvil empresarial o un desarrollador UWP empresarial? ¿O Enterprise Unity Dev?

Ninguna de las anteriores. Redactamos sistemas centrales para la gestión de activos y la integración bancaria. Algunas cosas en línea también.

@shederman , sospecho que esa podría ser la razón por la que no te preguntaron.

Por favor aclare

¿ Realmente estás diciendo que los únicos desarrolladores corporativos que MS admite ahora son los que realizan trabajo móvil para el 1% del mercado, las aplicaciones para UWP para um, el 5% de los usuarios que se preocupan y el desarrollo de juegos? Fuera de todo el espectro de desarrollo, la EM está dando la espalda a todo menos a eso .

Umm. No.

Estoy diciendo que los cambios se produjeron después de hablar con _ esos_ grupos, por eso no se les preguntó. Microsoft tiene que dar soporte a todos sus desarrolladores, no solo a los desarrolladores asp.

Sí, así que si van a apoyar a todos sus desarrolladores, tal vez deberían hablar con todos los desarrolladores. Quizás simplemente hablar con un subconjunto seleccionado del 5% de los desarrolladores empresariales no sea una buena forma de evaluar las opiniones de los desarrolladores empresariales en su conjunto.

Entonces, para que se escuche la opinión de un gran banco, ¿debemos cambiar todo nuestro desarrollo a UWP / Unity / Mobile?

Eso es ridículo.

tal vez deberían hablar con todos los desarrolladores.

¿No es eso lo que han estado haciendo durante los últimos 2 años o más?

@shederman Entonces, solo porque a usted personalmente no se le preguntó, ¿está insinuando que nadie más que cubra su rango de desarrollo estuvo involucrado?

Además, deje de inventar esos números, eso es ridículo.

@poke Estoy preguntando quién estuvo involucrado. Estoy diciendo que escuché que se consultó a los desarrolladores empresariales de materia oscura y les dije que yo estaba en el banco y no lo estábamos, entonces, ¿quién era exactamente?

De hecho, pensé que los números eran bastante generosos, pero está bien.

@shederman Creo que estás investigando demasiado todo esto. El enfoque durante los últimos 2 años ha estado directamente en el lado de asp.net, pero a medida que la palabra .net core comenzó a extenderse, mucha gente comenzó a preguntarse "¿Cómo puedo usar esto?". No era un trato de trastienda, era gente pidiendo literalmente años . Solo tiene que mirar a su alrededor para ver que muchas personas querían más de .net core.

También está la cuestión de las solicitudes de soporte empresarial reales de las grandes organizaciones que desean saber cómo transferir sus cosas existentes para que sean multiplataforma; probablemente no se le "preguntó" porque no necesitaba que alguien de Microsoft le dijera eso qué que está intentando hacer va más allá del alcance del proyecto.

Otra forma de verlo, y la forma en que yo lo veo personalmente, es que se le preguntó, se le preguntó en el momento en que se hizo el anuncio hace meses. A pesar de todos los gritos de las personas que dicen que las decisiones se tomaron sin consultar a nadie, Microsoft ha declarado en repetidas ocasiones que todavía están trabajando en los detalles, que todavía no tienen las piezas finales juntas y ahora es el momento de expresar su opinión . Scott Hunter incluso dijo que si la gente _realmente_ quiere project.json como una opción, considerarán mantenerlo. Ve a ver la nota clave de dotnetconf si no me crees.

@neoKushan Aprecio que Scott haya retrocedido un poco diciendo que considerarían mantenerlo, pero realmente debe haber un punto único y centralizado para que las personas expresen que esto es lo que quieren, de lo contrario, el problema project.json seguirá apareciendo en discusiones en todas partes. También significa que, cuando se mencione, todos pueden responder con el mismo "oye, considerarán quedárselo si los desarrolladores realmente lo quieren, aquí es donde debes avisarles".

project.json fue un buen paso. Pero fue ingenuo en mi opinión. No tiene en cuenta que la gente querría tener proyectos híbridos escritos en C ++ o F #. Algunas de sus primeras decisiones de diseño, como dnx y el uso de nuget como unidad de ensamblaje, no fueron factibles para el ecosistema dotnet en su conjunto. Lo que está viendo es que en el proceso de traer armonía a dotnet, tienen que tomar estas decisiones difíciles.

Bifurcar y reinventar, en mi opinión, no ayudará al ecosistema dotnet, solo lo dañará. Node and Go (especialmente Go) son muy atractivos para los principiantes porque tienen plataformas / herramientas homogéneas y consistentes.

Encuentro el argumento completo de XML vs JSON tonto porque en otros 5 años, será JSON vs YAML y luego YAML vs Groovy (por ejemplo, gradle). XML no es tan maligno como todos creen. MSBuild está muy maduro y tiene una gran inversión que beneficiará a todos.

Dicho esto, se debe hacer MUCHO trabajo con MSBuild para asegurarse de que puede obtener la misma o, al menos, una forma menos dolorosa de usar y editar archivos csproj. Luego, mueva las dependencias de nuget a un archivo nuget.json. Haga uso de la convención sobre la configuración de modo que si está en el "camino feliz", su csproj estará casi vacío, un poco como web.config hoy. y luego tener opciones de cli que modifiquen el csproj

Para mí, extrañaré project.json pero no por las razones que crees. Los proyectos en C # estarán bien. Lo echaré de menos debido a F # Preferí editar project.json para el orden de compilación en lugar de editar msbuild. Nuevamente, no porque xml sea malo, sino porque los archivos fsproj tienen mucha hinchazón provocada por msbuild

Mi problema con esta decisión fue principalmente la forma en que el archivo csproj tenía menos que ver con xml / json y mucho más con lo que eligieron incluir en el archivo csproj. Contenía la definición del proyecto, contenía la configuración del IDE, contenía los pasos de compilación, contenía las referencias ...

No hay mucho que _no_ haya terminado en esa cosa. Esto lo hizo terrible y solo se agrava cuando tener que lidiar con msbuild es bastante arcano a veces. Si está realmente interesado en hacer que .NET Core sea bueno y no solo funcione, haga que el archivo del proyecto sea independiente de las herramientas de compilación. Debería poder especificar cuál es mi proyecto y de qué depende, independientemente de cómo construirlo. Sin mencionar que esto comienza a permitirnos la elección de herramientas, incluso si la opción inicial solo está respaldada por msbuild en este momento.

Estoy de acuerdo con ésto. Al final del día, el problema clave con csproj es que
lo hace todo.

Me gusta el término medio que sugiere PatriotBob ...

El martes 21 de junio de 2016 a la 1:28 p.m. PatriotBob [email protected] escribió:

Mi problema con esta decisión fue principalmente la forma en que el archivo csproj era menos
sobre xml / json y mucho más sobre lo que eligieron incluir en el csproj
Archivo. Contenía la definición del proyecto, contenía la configuración del IDE,
contiene pasos de construcción, contiene referencias ...

No hay mucho que _no_ haya terminado en esa cosa. Esto lo hizo
terrible y solo se agrava cuando tener que lidiar con msbuild
bastante arcano a veces. Si está interesado en hacer que .NET Core sea bueno
y no solo el trabajo, hace que el archivo del proyecto sea independiente para construir herramientas. Yo debería
poder especificar cuál es mi proyecto y de qué depende por separado de
cómo construirlo. Sin mencionar que esto comienza a permitirnos la elección de
herramientas, incluso si la opción inicial solo está respaldada por msbuild en este momento.

-
Estás recibiendo esto porque comentaste.
Responda a este correo electrónico directamente, véalo en GitHub
https://github.com/aspnet/Home/issues/1433#issuecomment -227511911, o silenciar
la amenaza
https://github.com/notifications/unsubscribe/AKh-zsedLYg_PToadpD-_ewZPci0oHGCks5qOB8rgaJpZM4IcGCt
.

Todo el XML es malo, JSON es un gran alboroto. Me gusta lo que dice PatriotBobo.

administrar el proyecto as / w completamente desde npm package.json nunca se ha hecho de manera tan simple y concisa declarar mi proyecto, construir mi proyecto, actualizar mi proyecto (por ejemplo, greenkeeper), leer / escribir / analizar datos sobre mi proyecto, y publicar mi proyecto tan fácil. _tan fácil. como muchos de nosotros, mi historial está en c ++ / java / python / node, con play en otros. Anhelo la experiencia npm en todos mis proyectos ahora.

el project.json prometió producir estas mismas características. Creo que es un modelo que vale la pena emular, sin sacrificar la simplicidad y el poder.

si el equipo .net core team cree que la otra solución puede proporcionar estos rasgos, ¡ excelente y poder para ellos! sin embargo, no socave la belleza de la simplicidad a medida que avanza.

Además, entiendo que soy solo ruido en este punto en un hilo gigante. tal vez los moderadores deberían considerar cerrarlo y manejar la prueba de una manera más controlada. muchos buenos comentarios. tal vez un poco de trolling también: $ :)