2012-11-06 10 views
5

Pracuję nad szyfrowaniem procedur składowanych w projekcie korporacyjnym. Mamy garść SP, które powinny być chronione podczas produkcji.
Nie ma problemu z ustawieniem parametru WITH ENCRYPTION w każdym SP, który jest w sqlproj. Ale chcę uczynić tę dyrektywę opcjonalną: jeśli buduję projekt w trybie debugowania - nie stosuj tej opcji procedury, w przeciwnym razie - używaj go. Właściwie głównym celem jest uzyskanie bazy danych dla programistów bez szyfrowania, ale na produkcji - zaszyfrowane SP.
Używanie skryptu w zadaniu kompilacji PowerShell Mogę zmodyfikować wygenerowany plik sql iw rezultacie uzyskać skrypt z parametrem szyfrowania, ale zastanawiam się, jak to by działało z dacpac.
Jakieś sugestie?Metoda SKORZYSTANIA procedury składowanej w zależności od trybu kompilacji

Aktualizacja:

Po pewnym czasie spędzonym z gry msbuild. Postanowiłem zatrzymać się (przynajmniej na razie) na roztworze z zadania PowerShell skryptu po SqlCore cel:

<Import Project="$(ExtensionTasksPath)MSBuild.ExtensionPack.tasks" Condition="Exists('$(ExtensionTasksPath)MSBuild.ExtensionPack.dll')" /> 
    <UsingTask TaskFactory="PowershellTaskFactory" TaskName="CreateDecryptedScript" AssemblyFile="$(PowerShellTaskAssembly)" Condition="Exists('$(PowerShellTaskAssembly)')"> 
    <ParameterGroup> 
     <File Required="true" ParameterType="System.String" /> 
     <ResultFile Required="true" ParameterType="System.String" /> 
    </ParameterGroup> 
    <Task> 
     <![CDATA[  
     (Get-Content $file) | Foreach-Object {$_ -replace 'WITH ENCRYPTION', '--WITH ENCRYPTION'} | Set-Content $resultfile  
    ]]> 
    </Task> 
    </UsingTask> 
<Target Name="CreateDecryptedScript" AfterTargets="SqlCore"> 
    <CreateDecryptedScript File="$(OutputPath)$(CreateScriptFileName)" ResultFile="$(OutputPath)$(DecryptedScriptName)" Condition="Exists('$(PowerShellTaskAssembly)')" /> 
</Target> 

W rezultacie, po przebudowie projektu mamy skrypt służący do tworzenia bazy danych bez szyfrowania.

Ale wywoływane z projektu nie wymusza tego, aby coś się stało, a my zmienimy wszystkie SP za pomocą szyfrowania.

+0

Skrypt wdrażania po zmianie, aby zmienić SP, może załatwić sprawę. –

+0

@ aclear16 Tak, myślałem o tym, ale nie znalazłem żadnego rozsądnego rozwiązania. –

+0

Dodanie zmiennej poziomu projektu w miejsce "Z SZYFROWANIEM" może być opcją. W środowiskach programistycznych dodaj to jako pusty ciąg lub skomentowaną linię. W przypadku środowisk, które powinny być szyfrowane, użyj wartości "WITH ENCRYPTION". Ustaw te w swoich profilach publikowania. –

Odpowiedz

2

Łatwo jest odszyfrować "zaszyfrowane" procedury składowane. Sugeruję, żebyś nie kłopotał ich szyfrowania.

Jeśli musisz je zaszyfrować, proponuję krok po rozmieszczeniu DEV który odszyfrowuje każdym zaszyfrowanego procedury przechowywanej, jeden po drugim. Możesz łatwo stworzyć taki krok, używając sp_execsql i informacji pod linkiem.

+0

Tak, to jest sposób, w jaki może to działać, ale wciąż szukam elastycznego rozwiązania, które nie będzie wymagało manipulacji na SP na środowisku dev. –

+1

Myślę, że mnie źle zrozumiałeś. Chodzi mi o to, żeby w ogóle ich nie szyfrować - to strata czasu. – Ben

+0

Ohh ... Rozumiem. Ale to nie jest moja decyzja. I niestety wciąż potrzebuję szyfrowania SP. Ale dzięki za wskazanie. +1) –

Powiązane problemy