From 480e423124ef49807acc0fb221a0e40093c87c39 Mon Sep 17 00:00:00 2001
From: Alberto Balbo <alberto.balbo.96@gmail.com>
Date: Fri, 7 Aug 2026 16:27:40 +0200
Subject: [PATCH] Togli la pubblicazione dalla obj/ condivisa: rompeva la
 compilazione di debug

Sintomo: una raffica di CS2001 "file di origine MainWindow.g.cs non trovato" su
otto file .g.cs, lanciando la normale compilazione di debug da VS Code, senza che
il codice fosse cambiato. Il classico guasto intermittente della compilazione WPF.

Causa: il target Pubblica usava la sola opzione -o, che sposta il risultato ma
lascia gli INTERMEDI nella obj/ del progetto, cioe' la stessa cartella che usa la
compilazione di debug. La compilazione WPF genera un progetto temporaneo
_wpftmp.csproj a ogni giro, e quando ci trova dentro lo stato di un'altra
configurazione smette di produrre le classi parziali dello XAML. Bastava
pubblicare mentre si compilava in VS Code, o subito prima, per rompere tutto.

Era gia' il rimedio adottato per i test, dove artifacts-path era stato messo
proprio per questo; il target Pubblica era rimasto indietro. Le due opzioni
convivono: artifacts-path sposta gli intermedi, -o continua a decidere dove
finisce l'eseguibile.

Verificato ripetendo tre volte la sequenza che rompeva - pubblica, poi compila in
debug - con la obj/ svuotata all'inizio: zero errori tutte e tre le volte, e la
pubblicazione non crea piu' obj/Release.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
---
 Mimante/build/Release.proj | 15 ++++++++++++++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/Mimante/build/Release.proj b/Mimante/build/Release.proj
index 715bc84..e2ea1de 100644
--- a/Mimante/build/Release.proj
+++ b/Mimante/build/Release.proj
@@ -433,9 +433,22 @@
   <Target Name="Pubblica" DependsOnTargets="DeterminaVersione">
     <Message Importance="High" Text="== Pubblicazione dell'eseguibile ($(V)) ==" />
 
+    <!-- ── Perché gli intermedi vanno altrove ──────────────────────────────
+         La sola opzione -o sposta il risultato ma lascia gli INTERMEDI nella obj/
+         del progetto, che è la stessa che usa la compilazione di debug lanciata da
+         VS Code. La compilazione WPF genera un progetto temporaneo `_wpftmp.csproj`
+         a ogni giro, e quando ci trova dentro lo stato di un'altra configurazione
+         smette di produrre le classi parziali dello XAML: si ottiene una raffica di
+         CS2001 «file di origine MainWindow.g.cs non trovato», a giri alterni, senza
+         che il codice sia cambiato.
+
+         Era già il rimedio adottato per i test; qui era rimasto indietro, e bastava
+         pubblicare mentre si compilava in VS Code per rompere la compilazione di
+         debug. L'opzione artifacts-path sposta gli intermedi, la -o continua a
+         decidere dove finisce l'eseguibile: le due convivono. -->
     <Exec WorkingDirectory="$(Radice)"
           EnvironmentVariables="$(AmbientePulito)"
-          Command="dotnet publish &quot;$(Csproj)&quot; -c Release -r win-x64 --nologo -v q --self-contained true -p:PublishSingleFile=true -p:IncludeNativeLibrariesForSelfExtract=true -p:EnableCompressionInSingleFile=true -p:PublishReadyToRun=true -p:PublishTrimmed=false -p:Version=$(V) -p:AssemblyVersion=$(V).0 -p:FileVersion=$(V).0 -p:InformationalVersion=$(V) -o &quot;$(CartellaPubblicazione)&quot;" />
+          Command="dotnet publish &quot;$(Csproj)&quot; -c Release -r win-x64 --nologo -v q --artifacts-path &quot;$(CartellaProve)&quot; --self-contained true -p:PublishSingleFile=true -p:IncludeNativeLibrariesForSelfExtract=true -p:EnableCompressionInSingleFile=true -p:PublishReadyToRun=true -p:PublishTrimmed=false -p:Version=$(V) -p:AssemblyVersion=$(V).0 -p:FileVersion=$(V).0 -p:InformationalVersion=$(V) -o &quot;$(CartellaPubblicazione)&quot;" />
 
     <Error Condition="!Exists('$(CartellaPubblicazione)\AutoBidder.exe')"
            Text="Pubblicazione fallita: AutoBidder.exe non trovato." />