Estoy de acuerdo con muchas de las respuestas aquí. .NET no tenía una gran cantidad de IDE independientes, usó Visual Studio para escribir su código, administrar sus dependencias, etc. La solución en VS es lo suficientemente buena para MSBuild, así que eso es lo que usa desde sus servidores de compilación.
Java, por otro lado, desarrolló muchos IDE y Java siguió una ruta de gestión de proyectos externos al IDE. Liberar al desarrollador para que use su IDE de elección. Recientemente comencé el entrenamiento cruzado de C # a Java y puedo decirles que el concepto de compilación de Maven es bastante extraño, pero luego de un tiempo me encanta y, lo que es más importante, veo lo que me ofrece el concepto de repositorio.
Ahora, cómo las dependencias administradas por VS requieren que agregue una referencia de proyecto o una referencia a una DLL. Esta adición de una referencia de DLL es defectuosa. ¿Cómo gestiona el cambio de versiones, cómo estructura las dlls de terceros a partir de fuentes externas e internas, así como las dlls que le gustaría incluir de su propio equipo pero no como referencia del proyecto? He realizado muchas soluciones temporales basadas en general en la estructura de directorios basada en archivos, pero ninguna de ellas es elegante o excelente cuando las versiones cambian. También dificulta la ramificación porque se convierte en una consideración en la forma en que se estructuran los directorios.
Ahora he trabajado con Java y repositorios públicos de mavan, super cool. He trabajado con Python y pip install de manera efectiva nuevamente extrayendo de repositorios públicos. Finalmente hice algunas cosas en C # nuevamente con VS 2015 y la integración con Nuget es exactamente lo que faltaba.
Ahora, en el entorno corporativo, los repositorios públicos no siempre son directamente accesibles, por lo que necesita repos corporativos. Nuevamente, los ecosistemas que no son de Microsoft están por delante en esto.
Básicamente, en resumen, Java evolucionó a partir de un entorno de código más abierto donde no se utilizó el mantenimiento del proyecto IDE, mientras que .NET evolucionó a partir de Visual Studio que administra el proyecto, y estas diferentes rutas significaron que los repositorios vendrán más tarde en Visual Studio.
Finalmente, y esta es mi observación, la comunidad Java tiende a usar más los marcos de otras personas, ya que las bibliotecas base de Java ofrecen menos. Mientras que la gente .NET escribe mucho más de su propio código. La comunidad java tiene un ecosistema más grande de patrones y prácticas, mientras que .NET nuevamente escribió su propio código o esperó a Microsoft. Esto está cambiando, pero nuevamente muestra por qué .NET está detrás de Java en el requisito de repositorios.