Mě touto hláškou obšťastnil sign-in dialog ve Visual Studiu v lab Virtual Machine, ale můžete ji potkat i jinde. V mém případě byl důvod v nepřiměřeně se rozcházejícím čase virtuálního stroje a času skutečného (na serverech MSFT).
Stejně tak například bez rozumného času nejde Windows Update.
Copy Local standardně zobrazuje hodnotu True, ale ve skutečnosti to znamená neuvedeno, protože v *.csproj souboru není nic uvedeno. Pokud běží build na stroji, který má assembly uložené v GAC, nebude knihovna zkopírována do složky bin.
Řešení je jednoduché, stačí hodnotu nastavit na False a zpět na True. Tím dojde k uložení informace do *.csproj souboru a sice v elementu Reference přibyde nový element Private s hodnotou True.
<Reference Include="Havit">
<HintPath>...</HintPath>
<Private>True</Private>
</Reference>
V projektu máme webovou aplikaci, která má Publish Profile, který má vytvořit Web Deployment balíček. Balíček se úspěšně vytváří jak při spuštění MSBuildu z Visual Studia, tak z příkazové řádky na vývojářském počítači, tak při spuštění z příkazové řádky na počítači s TFS Build Service. Jenže při spuštění z TFS Build Service se balíček nevytvoří.
Podoba publish profile, který byl vyroben pomocí UI ve Visual Studio 2013 je (plus mínus) takováto:
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<WebPublishMethod>Package</WebPublishMethod>
<DesktopBuildPackageLocation>TfsPublish\BalicekKteryChciVytvorit.zip</DesktopBuildPackageLocation>
<PackageAsSingleFile>true</PackageAsSingleFile>
...
</PropertyGroup>
</Project>
Důvodem, proč se balíček nevytváří je skutečnost, že Visual Studio do publish profilu vytvoří vlastnost DesktopBuildPackageLocation, jenže je očekávána hodnota vlastnosti PackageLocation.
A jak to, že v rámci VS a z příkazové řádky to funguje? Protože PackageLocation se v průběhu načítání C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\Web\Microsoft.Web.Publishing.targets nastaví podle DestopBuildPackageLocation.
<PackageLocation Condition="'$(PackageLocation)'=='' and !(('$(OutDir)' != '$(OutputPath)') Or ('$(IsDesktopBuild)' == 'False')) ">$(DesktopBuildPackageLocation)</PackageLocation>
Jenže jen za podmínky, kdy IsDesktopBuild není false (druhou podmínku není ukázanou výše třeba řešit). Otázkou je, kde se nastavuje hodnota vlastnosti IsDesktopBuild. Odpověď se skrývá v témže souboru:
<IsDesktopBuild Condition="'$(IsDesktopBuild)'=='' And '$(TeamFoundationServerUrl)' != ''">False</IsDesktopBuild>
A problém je objasněn – TFS Build Service nastavuje hodnotu TeamFoundationServerUrl, čímž se build liší od spuštění z příkazové řádky.
Nastavení vlastnosti PackageLocation bohužel nefunguje v rámci vlastního targetu, neboť to je již pozdě. Z vlastnosti se odvozují další vlastnosti během načítání target souborů.
Slides z mé přednášky 18.10.2014 pro konferenci MS Fest Brno:
Z přednášky jsem pořizoval záznam, který najdete na našem HAVIT YouTube Channelu:
Ve formulářovém poli chceme po uživateli e-mailovou adresu nebo třeba nový login name – jaké je jeho rozčarování, když po vložení adresy pomocí CTRL-V (zkopírované např. z Excelu), aplikace hlásí
nevalidní údaj.
Na vině jsou nechtěné mezery připojené za (a někdy i před) adresu.
Nechtěné mezery nám pomůže odstranit funkce aktivovaná událostí input -> na oninput řetězec trimujeme.
Provedeme to pouze, pokud se otrimovaný a původní řetězec liší (tj. je co trimovat) – pokud bychom to dělali bez této podmínky, tak vždy, když by uživatel ručně vepsal nějaký znak, skočil by mu kurzor v políčku na konec pole (i tehdy, pokud by něco editoval uprostřed textu).
if (formField.value != formField.value.trim())
{
formField.value = formField.value.trim();
}
Pro ASP.NET si můžeme vytvořit takovýto skin:
<asp:TextBox SkinID="TrimOnInput" oninput="if (this.value!=this.value.trim()) {this.value=this.value.trim();};" runat="server" />
Funkce se nehodí pro pole, která mají obsahovat mezeru mezi slovy (např. „Jan Novák“) – i když takové celé jméno lze do pole vložit pomocí CTRL-C, zcela určitě nebude možné jméno pohodlně napsat – pole se totiž chová tak, že na stisk mezerníku za slovem nereaguje.
Nejprve jsem myslel, že to dám k nám na interní wiki, ale mohlo by se to hodit i dalším…
Pokud potřebujete vytvořit nebo přejmenovat ve Windows Exploreru soubor/složku na jméno, které začíná tečkou (.tfignore, .svn, …), funguje jednoduchý trik – přidejte ještě jednu tečku na konec jména(např. „.tfignore.“). Windows Explorer to překousne a záměru je dosaženo.
…starý trik, ale občas si ho musím připomenout.
Microsoft SQL Server má nedokumentovanou uloženou proceduru, která usnadní vykonání stejného SQL příkazu pro více DB. Např. nalezení CLR assemblies přes všechny DB:
sp_MSForeachDB 'use [?]; SELECT DB_NAME(), * FROM sys.assemblies WHERE name LIKE ''Havit%'';'
Pokud chceme příkaz vykonat s výjimkou některých DB, můžeme použít IF:
sp_MSForeach 'IF ? NOT IN (''master'', ''msdb'', ''tempdb'', ''model'') USE [?]; -- atp'
(Pozor, že pokud dáte pod IF jenom USE, tak se Vám následný příkaz vykoná pro aktuální DB několikrát, protože neproběhne jenom přepnutí USE na jinou DB.)
Dneska ráno nás v práci uvítal critical ticket v HelpDesku, jednomu ze zákazníků „nešel web a všechno, co po přihlášení zkusil, vedlo na homepage“. Hned se nám spojilo, že to je web, na který kolega nastavoval přesměrování HTTP requestů na HTTPS a zkoušel si různé způsoby, jak to udělat.
Jeden z testů, které udělal, byl přes <httpRedirect> (HTTP Redirection). Pak od něj ale upustil a redirect nastavený přes IIS Manager zase vypnul.
Souhra okolností chtěla, aby toto zapnutí a vypnutí způsobilo poměrně velký problém.
Po IIS Manageru zůstalo v hlavním ~/web.configu webu toto:
<system.webServer> <httpRedirect enabled="false" destination="https://chester.xerox.cz" httpResponseStatus="Permanent" /> </system.webServer>
To by samo o sobě nevadilo. Peklo však nastalo v okamžiku, kdy se to potkalo s web.config soubory v podsložkách, v nichž byla různá specifická přesměrování od vývojářů:
<system.webServer> <httpRedirect enabled="true" exactDestination="true"> <add wildcard="/Old-URL.aspx" destination="New-URL.aspx"/> ... </httpRedirect> </system.webServer>
Když se to celé sečetlo, tak ve všech takových podsložkách se reaktivoval disablovaný redirect z rootového web.configu a veškeré requesty na resources v dané složce přesměrovával.
…další důvod proč nemám rád, když IIS Manager modifikuje web.config. Hlavním je ten, že při nasazování chci web.config přepisovat vždy celý novou verzí a jakékoliv production-specific volby z něj mít vyextrahovány třeba pomocí atributu configSource.
Řeším to tak akorát v četnosti, kdy právě zapomenu, jak se to přesně dělá. Tedy pro připomenutí, stačí do registry přidat:
Windows Registry Editor Version 5.00 [HKEY_CLASSES_ROOT\*\shell\Notepad2] [HKEY_CLASSES_ROOT\*\shell\Notepad2\command] @="\"C:\\Program Files\\Notepad2\\Notepad2.exe\" \"%1\""
…název klíče odpovídá textu položky v menu.
Připravený soubor: Notepad2 Shell Context Menu.reg
HAVIT Knowledge Base 