Simple SDK for custom artifacts (EXEs / DLLs) generated by external tool
Nadie ha tomado este issue todavía.
Evaluación
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Aptitud para principiantes
- 35/100
- Tipo de issue
- Nueva funcionalidad
- Claridad
- Bastante claro
- Estado de actividad
- Estancado
- Área
- build-system
Línea de trabajo
Comienza leyendo el comportamiento del SDK Microsoft.Build.NoTargets en torno a GetTargetPath y el SDK importado manualmente. Define cómo deben funcionar los targets mínimos de Build y Clean y cómo los archivos generados, como DLLs, PDBs y otros artefactos relativos, se propagan a través del wrapper de C# hasta el directorio de salida final de FooApp. Se considera terminado cuando una herramienta externa de Rust, Zig o similar puede compilar y limpiar artefactos, mientras los proyectos referenciados los copian transitivamente.
Escrito por el modelo de indexación a partir del texto del issue.
Descripción
I'm trying to use the Microsoft.Build.NoTargets SDK to generate a project that builds a Rust cdylib (.dll / .so) and produces the following artifacts:
- foo.dll
- foo.pdb
- ...
What I'd like is to have a way to specify all of this in the most elegant way (not just tied to Rust) but the Microsoft.Build.NoTargets SDK explicitly disables the GetTargetPath target (and other stuff) and it makes you import the SDK manually (instead of just using <Project Sdk="...">) because it's intended to be a way to just launch some tools that produce no artifacts / assemblies.
So it would be nice to have a minimal SDK that just invokes two main targets (Build and Clean) and a target that allows specifying which generated files are to be copied transitively (with a folder structure relative from the build directory, like BUILD/res/foo.bin).
My concrete goal is to have a Rust (or Zig / whatever) native DLL project (libfoo-rs) that is referenced by a C# wrapper project (LibFoo) that gets used by a C# Exe project (FooApp) such that when running FooApp in VS, everything gets copied in the final Output directory.
- Lenguaje dominante
- C#
- Estrellas
- 508
- Forks
- 94
- Merge medio
- 11 h 34 min
- PR fusionados (30 d)
- 1
Preparar el entorno
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Más de microsoft/MSBuildSdks
-
Dificultad 3/5 1-2 días Aptitud para principiantes 35/100
microsoft/MSBuildSdks#652 · 2 comentarios ·
-
Dificultad 5/5 Más de una semana Aptitud para principiantes 25/100
microsoft/MSBuildSdks#646 ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 25/100
microsoft/MSBuildSdks#644 · 1 comentario ·
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 45/100
microsoft/MSBuildSdks#642 ·
-
Dificultad 4/5 3-5 días Aptitud para principiantes 35/100
microsoft/MSBuildSdks#635 ·
Todos los issues de microsoft/MSBuildSdks
Issues similares
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 72/100
fluentassertions/fluentassertions#3353 ·
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 65/100
-
Dificultad 2/5 Medio día Aptitud para principiantes 78/100
unoplatform/uno#24769 ·
Los mantenedores suelen responder en 1 día
-
bug
Dificultad 2/5 1-3 horas Aptitud para principiantes 75/100
AvaloniaUI/Avalonia#22323 ·
Los mantenedores suelen responder en 1 día
-
Dificultad 2/5 1-3 horas Aptitud para principiantes 88/100
microsoft/onnxruntime-genai#2633 ·
Los mantenedores suelen responder en 1 día