Closed enteo-tw closed 2 years ago
To samo. Pobrudziłem sobie trochę ręce i wyszedł mi taki oto fix: https://github.com/soneta/Soneta.MsBuild.SDK/pull/50
Fix dodaje backslash na końcu ścieżki, dzięki czemu nie generuje się dodatkowy cudzysłów na końcu ścieżki.
To samo. Pobrudziłem sobie trochę ręce i wyszedł mi taki oto fix:
50
Fix dodaje backslash na końcu ścieżki, dzięki czemu nie generuje się dodatkowy cudzysłów na końcu ścieżki.
Dzięki.
U mnie pojawił się kolejny problem:
$(OutputPath) - u mnie zwraca pełną ścieżkę np. D:\Builds\Produkt XYZ\debug
więc dopiero jak poprawiłem na
<StartArguments>/extpath="$(OutputPath)\"</StartArguments>
działa u mnie prawidłowo.
Dziwne, bo wygląda na to, że projekty SDK-style ma błąd w tym zakresie. Taka sama definicja w projekcie starego typu działa poprawnie.
Zgłosiłem ten problem na netzam 6 lipca i dostałem odpowiedź, że mam wyłączyć zgłaszanie wyjątków w VS :). Dodatkowo w wersji sdk 1.0.4 ten mechanizm działał bez problemów.
To samo. Pobrudziłem sobie trochę ręce i wyszedł mi taki oto fix:
50
Fix dodaje backslash na końcu ścieżki, dzięki czemu nie generuje się dodatkowy cudzysłów na końcu ścieżki.
Witam Przede wszystkim dziękuję za zaangażowanie - stawiam piwo za pierwszy PR z zewnątrz. Temat chwilę analizowałem wcześniej i wyszło mi, że to problem z niedozwolonymi znakami na etapie przekazywania zmiennych msbuild do taska exec i nie było tam czystego rozwiązania biorąc pod uwagę różne przypadki zastosowania.
W przyszłym tygodniu zerknę na rozwiązanie z PR i dam znać.
To samo. Pobrudziłem sobie trochę ręce i wyszedł mi taki oto fix:
50
Fix dodaje backslash na końcu ścieżki, dzięki czemu nie generuje się dodatkowy cudzysłów na końcu ścieżki.
Dzięki. U mnie pojawił się kolejny problem: $(OutputPath) - u mnie zwraca pełną ścieżkę np. D:\Builds\Produkt XYZ\debug więc dopiero jak poprawiłem na
<StartArguments>/extpath="$(OutputPath)\"</StartArguments>
działa u mnie prawidłowo.
Czy w Pana przypadku nie ma jakiejś ingerencji w katalog wyjściowy w pliku projektu lub directory.build.props? Bo wygląda jakby pojawiło się tam jakieś bezwzględne wskazanie.
Zgłosiłem ten problem na netzam 6 lipca i dostałem odpowiedź, że mam wyłączyć zgłaszanie wyjątków w VS :). Dodatkowo w wersji sdk 1.0.4 ten mechanizm działał bez problemów.
Przede wszystkim przepraszam za "niskiej jakości" ;) sugestię ze wsparcia. Można prosić o namiar na to zgłoszenie? Mam wrażenie, że jedyną różnicą w tym zakresie jest ujęcie OutputPath w ", bo jeżeli tak nie było, to każda spacja w tej ścieżce powodowała, że wyraz po niej stawał się kolejnym argumentem wywołania, zamiast kontynuacją ścieżki.
Panie Bartoszu, netzam ZS/2021/6811 (obecnie zamknięte) - to nawet nie chodzi o to, że "niskiej jakości", ale jak Pan wie "poza pewnymi wyjątkami" staram się być względem moich partnerów w rozmowie uprzejmy i fajnie aby i oni odpowiadali tym samym. Dziękuję za odpowiedź na moje issue :)
To samo. Pobrudziłem sobie trochę ręce i wyszedł mi taki oto fix:
50
Fix dodaje backslash na końcu ścieżki, dzięki czemu nie generuje się dodatkowy cudzysłów na końcu ścieżki.
Dzięki. U mnie pojawił się kolejny problem: $(OutputPath) - u mnie zwraca pełną ścieżkę np. D:\Builds\Produkt XYZ\debug więc dopiero jak poprawiłem na
<StartArguments>/extpath="$(OutputPath)\"</StartArguments>
działa u mnie prawidłowo.Czy w Pana przypadku nie ma jakiejś ingerencji w katalog wyjściowy w pliku projektu lub directory.build.props? Bo wygląda jakby pojawiło się tam jakieś bezwzględne wskazanie.
W Visual Studio 2019 we właściwościach projektu, w zakładce Build w Output Path podaję ścieżkę do zupełnie innego katalogu np. "D:\Builds\Produkt XYZ\" i Visual Studio w tej postaci bezwzględnej tę ścieżkę zapisuje, co może się wydawać dziwne, ponieważ starsze wersje Visuala zwykle taką ścieżkę zamieniały na ścieżkę względną, coś w stylu: "\..\..\..\Builds\Produkt XYZ".
Utworzyłem PR #52.
To samo. Pobrudziłem sobie trochę ręce i wyszedł mi taki oto fix:
50
Fix dodaje backslash na końcu ścieżki, dzięki czemu nie generuje się dodatkowy cudzysłów na końcu ścieżki.
Dzięki. U mnie pojawił się kolejny problem: $(OutputPath) - u mnie zwraca pełną ścieżkę np. D:\Builds\Produkt XYZ\debug więc dopiero jak poprawiłem na
<StartArguments>/extpath="$(OutputPath)\"</StartArguments>
działa u mnie prawidłowo.Czy w Pana przypadku nie ma jakiejś ingerencji w katalog wyjściowy w pliku projektu lub directory.build.props? Bo wygląda jakby pojawiło się tam jakieś bezwzględne wskazanie.
W Visual Studio 2019 we właściwościach projektu, w zakładce Build w Output Path podaję ścieżkę do zupełnie innego katalogu np. "D:\Builds\Produkt XYZ" i Visual Studio w tej postaci bezwzględnej tę ścieżkę zapisuje, co może się wydawać dziwne, ponieważ starsze wersje Visuala zwykle taką ścieżkę zamieniały na ścieżkę względną, coś w stylu: "......\Builds\Produkt XYZ".
Tu można zobaczyć ścieżki (wstawiamy do Directory.build.props) wiadomość w Output Build:
<Target Name="MessageBeforeBuild" BeforeTargets="Build">
<!--
<PropertyGroup>
<StartProgram>"$(StartProgram)"</StartProgram>
<StartArguments>/extpath=".\"</StartArguments>
</PropertyGroup>
-->
<Message Text="RunCommand $(StartProgram)" Importance="high" />
<Message Text="RunArguments $(StartArguments)" Importance="high" />
</Target>
Odnośnie ustawiania ścieżek bezwzględnych, można by zrobić coś w stylu:
<StartArguments Condition="$([System.IO.Path]::IsPathFullyQualified('$(OutputPath)'))">/extpath="$(OutputPath)"</StartArguments>
<StartArguments Condition="!$([System.IO.Path]::IsPathFullyQualified('$(OutputPath)'))">/extpath="$(MSBuildProjectDirectory)\$(OutputPath)"</StartArguments>
Nie jestem jednak pewien, czy to dobra droga. Jeśli celem jest umożliwienie kompilacji do pewnego stałego katalogu i uruchamiania projektów z tym ustawieniem, to trzeba by to chyba rozwiązać bardziej systemowo.
Niezależne uruchamianie projektów z /bin
, gdy te mogą być zależne od innych, albo gdy inne projekty modelują nowe tabele jest mało elastyczne.
PS. Do powyższego - trzy odwrotne apostrofy (backtick `).
@bartcho czy coś w tym temacie drgnęło, bo ja mam cały czas błąd z niedozwolonymi znakami w ścieżce. Czy muszę coś zaktualizować, pobrać jakąś poprawkę?
Dziś wydamy SDK 1.1.1 z tą poprawką.
Dziś wydamy SDK 1.1.1 z tą poprawką.
Dziękuję za informację.
Wersja zawierająca poprawkę jest już dostępna.
Korzystając z Soneta.Sdk 1.1.0 nie da się uruchomić projektu, generowane są nieprawidłowe argumenty uruchomieniowe (coś jest namieszane z cudzysłowami):