search

soneta / Soneta.MsBuild.SDK

Sdk stworzone przez firmę Soneta pozwalające automatycznie skonfigurować oraz uzupełnić projekty dodatków o niezbędne elementy potrzebne do współpracy z oprogramowaniem enova.
MIT License
8 stars 12 forks source link

SDK 1.1.0 - "Niedozwolone znaki w ścieżce" #49

Closed enteo-tw closed 2 years ago

enteo-tw commented 3 years ago

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):

obraz

System.Environment.GetCommandLineArgs() {string[2]} [0]: "C:\Program Files (x86)\Soneta\enova365 2106.0.0.0\SonetaExplorer.exe"

SylwesterZarebski commented 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.

enteo-tw commented 2 years ago

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.

SylwesterZarebski commented 2 years ago

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.

jasickia commented 2 years ago

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.

bartcho commented 2 years ago

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ć.

bartcho commented 2 years ago

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.

bartcho commented 2 years ago

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.

jasickia commented 2 years ago

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 :)

enteo-tw commented 2 years ago

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".

SylwesterZarebski commented 2 years ago

Utworzyłem PR #52.

jasickia commented 2 years ago

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>
SylwesterZarebski commented 2 years ago

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 `).

jasickia commented 2 years ago

@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ę?

SebastianWabnik commented 2 years ago

Dziś wydamy SDK 1.1.1 z tą poprawką.

jasickia commented 2 years ago

Dziś wydamy SDK 1.1.1 z tą poprawką.

Dziękuję za informację.

damdyn commented 2 years ago

Wersja zawierająca poprawkę jest już dostępna.