2013-04-25 12 views
7

Pobrałem SlowCheetah do starej aplikacji formularzy sieci .NET 3.5, aby dodać transformacje do pliku web.config.Używanie konfiguracji SlowCheetah Transformacja na Web.config w aplikacji 3.5 Web Forms

Użyłem SlowCheetah z usługami Windows i aplikacjami konsolowymi do transformacji app.config z sukcesem w przeszłości. W takich przypadkach konfiguracja zostanie przekształcona i umieszczona w koszu jako ApplicationName.exe.config.

Jednak w przypadku tej aplikacji formularzy internetowych plik konfiguracyjny nigdy nie trafi do pojemnika, ponieważ witryny formularzy internetowych są zbudowane z samych plików .dll umieszczonych w koszu, a katalog IIS wskazuje katalog główny w celu uruchomienia witryny. Tak więc zamiast web.config, który został włączony do procesu kompilacji i spakowany w koszu, jest pozostawiony sam w lokalizacji głównej.

Żadne transformacje nie są stosowane do pliku web.config w katalogu głównym, co jest dobre, ponieważ plik web.config w katalogu głównym jest w źródłowej kontroli i jest plikiem, w którym dokonujemy transformacji.

Byłbym szczęśliwy z dołączeniem pliku web.config do kompilacji, dzięki czemu slowCheetah przekształci go, a następnie upuści w koszu. Musielibyśmy ręcznie wyjąć go z kosza i umieścić go z powrotem na poziomie root na naszych serwerach, ale warto byłoby mieć transformacje.

Czy ktoś wie, jak przekonwertować transformaty na mój plik web.config lub włączyć go do procesu kompilacji, dzięki czemu slowCheetah może działać na swój sposób?

Dzięki!

Aktualizacja

I zmodyfikowane właściwości web.config i jest obecnie zawarte w budowie, jednak przemiany nie są jeszcze stosowane do niego.

Budowa Działanie: osadzonego zasobu

Kopiuj do dyrektora wyjściowe: Copy Zawsze

Odpowiedz

5

Rozwiązanie

I przemianowany na Web.config w naszą kontrolą źródłowego Web.template.config i dodane przekształcenia Web.template.Debug.config i Web.template.Release.config

Następnie wyładuj plik projektu i edytuj plik .csproj xml dodanie następujących elementów

Spowoduje to utworzenie nowego pliku Web.config w katalogu głównym. Woot!

<PropertyGroup> 
    <PrepareForRunDependsOn> 
    $(PrepareForRunDependsOn); 
    WebConfigTransform; 
    </PrepareForRunDependsOn> 
</PropertyGroup> 
<Target Name="WebConfigTransform"> 
    <Message Text="Configuration: $(Configuration): Web.template.$(Configuration).config" /> 
    <TransformXml Source="Web.template.config" 
       Transform="Web.template.$(Configuration).config" 
       Destination="Web.config" /> 
</Target> 
1

znaleźć lepszego rozwiązania - jedno bez zmiany nazw plików do .template.config.

Wklej następujące elementy do pliku .csproj formularzy sieci Web.

<Target Name="BeforeBuild"> 
    <Delete Files="$(TEMP)\Web.TEMP.config" /> 
    <Copy SourceFiles="Web.config" DestinationFiles="$(TEMP)\Web.TEMP.config" /> 
    <TransformXml 
     Source="$(TEMP)\Web.TEMP.config" 
     Transform="Web.$(Configuration).config" 
     Destination="Web.config" /> 
    </Target> 
+0

Problem polega na tym, że tworzy się nieco odwołanie cykliczne. Powiedzmy, że masz transformację, która wstawia elementy. Przy pierwszym uruchomieniu zajmie to, co znajduje się w web.config i wstawi nowe elementy, a za drugim razem, gdy uruchomisz transformację, wstawisz duplikaty elementów. Pamiętaj też, że jeśli web.config jest pod kontrolą źródła, czy chcesz, aby cały czas się zmieniał? – Michael

+0

Zgadzam się z okrągłym problemem. Chociaż używamy transformacji "Ustawień", więc działa ona doskonale dla nas. –

+0

Posiadanie Web.config pod kontrolą źródła jest dla nas ważne. Tak więc rozwiązanie. Ale zgadzam się, że twoje rozwiązanie jest lepsze. –

Powiązane problemy