Nastavení Image.Source z kódu

myImage.Source = new BitmapImage(new Uri("images/myImage.jpg", UriKind.Relative));

mstsc.exe /admin

Pokud jste u RDP clienta byli zvyklí na přepínač /console, pak vězte, že ho Microsoft přejmenoval na přepínač /admin:

mstsc.exe /admin

Cílovou adresu je možné předat přepínačem /v

mstsc.exe /v:my.server.com

Je to zjednodušeně řečeno připojení na jednu vyhrazenou session RDP (přesněji řečeno lokální konzoli, jako u běžného Remote Desktopu), kde se zejména neuplatňuje limit 3 admin-session, nýbrž se v rámci té jedné vyhrazené session připojení navzájem vykopávají (a tedy je to řešení, když vás server nechce pustit na RDP kvůli limitu 3 a Vám by jinak nezbývalo, než vyrazit k serveru a otevřené session sestřelit). Potřeba je pochopitelně účet s administrátorskými právy.

Exchange 2007: Podivná authentizace starších klientů (Outlook 2003, Outlook Express)

Vynikající chybu jsem objevil v Outlook Expressu (z Win2k3 Serveru). Při připojení na standardní instalaci Exchange 2007 se při zaškrtnutí „Přihlašovat k serveru odchozí pošty“ – „Použít stejné přihlašovací údaje jako server příchozí pošty“ – klient neauthentizuje vůči serveru. Pokud však využijeme možnosti zadat authentizační údaje ručně, OE se přihlásí a poštu odešle. Pokud opět přepnete zpět na „Použít stejné jako příchozí“, tak odesílání pošty funguje, ale jen než restartujete OE.

Pominu-li tento bug v Outlook Expressu, tak problém je v tom, že standardní instalace Exchange 2007 nemá povolenu Basic authentization, resp. ji má pod podmínkou „Offer Basic Authentization only after starting TLS“. Exchange server tak v odpovědi na EHLO odpovídá jen AUTH NTLM a nenabízí AUTH LOGIN.

AUTH LOGIN povolíme odšrktnutím „Offer Basic Authentization only after starting TLS“ (Server Configuration – Hub Transport – Receive Connector – Properties – Authentication).

Exchange 2007 Setup: Topology discovery failed, error 0x80040a02 (DSC_E_NO_SUITABLE_CDC).

Pokud budete během instalace Exchange 2007 obdařeni touto príma chybou, vězte, že je potřeba zapnout IPv6 a nastavit serveru IPv6 adresu.

Podrobnosti zde.

Pozor na FileUpload v UpdatePanelu

Po prázdninové odmlce jsem tu zpět s další čerstvou zkušeností, kterou jsme udělali na jednom z našich projektů.

Story

Společné uživatelské rozhraní pro vytváření nových a editaci stávajících záznamů mělo části, které byly použitelné jen pro existující objekty, mj. i možnost připojení souborů pres control FileUpload. Části použitelné jen u existujících objektů byly skryty pomocí Visible=“fase“ a zobrazovány pomocí UpdatePanelu, který je zobrazil po uložení nového objektu.

Problém byl v tom, že u nově vytvořených objektů nebylo možné připojit soubory, zatímco u existujících objektů to bez problémů šlo. Ukázalo se, ze control FileUpload v postbacku žádný soubor nedostane (HasFile bylo false), přestože uživatel soubor do formuláře zadal. Stejně se to chovalo ve všech prohlížečích a Fiddler potvrdil, že se z klienta žádný soubor nepřenesl.

Primitivní testovací kód by mohl vypadat třeba takto:

<form id="form1" runat="server">
     <asp:ScriptManager EnablePartialRendering="false" runat="server" />
        <asp:UpdatePanel runat="server">
            <ContentTemplate>
                <asp:FileUpload ID="FileFU" Visible="false" runat="server" />
                <asp:Label ID="HasFileLb" runat="server" />
                <asp:Button ID="SaveBt" Text="Save" runat="server" />
            </ContentTemplate>
        </asp:UpdatePanel>
</form>
void SaveBt_Click(object sender, EventArgs e)
{
    FileFU.Visible = true;
    HasFileLb.Text = FileFU.HasFile.ToString();
}

Po chvilce ladění se ukázala příčina problému. V režimu editace existujícího objektu formulář již od prvního requestu renderoval control FileUpload, který si sám do elementu form doplňuje potřebný atribut enctype=“multipart/form-data“, zatímco v režimu založení nového objektu se control FileUpload renderoval až AJAXem z UpdatePanelu po uložení nového objektu. UpdatePanel však v DOM stránky vymění jen svoji část a element form zůstává nedotčen, bez atributu enctype.

Summary

Pozor na to, ze AJAXovy partial rendering pomoci UpdatePaneliu vymění pouze určitou část DOM stránky a nesmi se zapomínat na vztahy teto části se zbytkem stránky. Většinou jsou tyto vztahy zřejmé, záludnost s FileUpload a atributem enctype vsak může pozlobit.

Možným řešením je například nastavování hodnoty atributu z kódu už při prvním requestu, přestože control FileUpload ještě na stránce není:

this.Page.Form.Enctype = "multipart/form-data"

Detailní ASP.NET Request + WebForm Page LifeCycle diagram

Pokud se zabýváte technologií ASP.NET do hloubky, může se Vám hodit můj „ASP.NET 2.0/3.5 Request + Page LifeCycle Diagram“:

ASP.NET LifeCycle 2

Jedná se o první verzi mého diagramu, který hodlám dále graficky vylepšovat a zpřehledňovat. Až mi zbyde chvilka, dám sem i PDF verzi k tisku. Stejnětak je možné, že jsem v něm někde udělal chybu. Pokud tedy nějakou nesrovnalost objevíte, dejte mi prosím vědět.

Červeně jsou označena místa, kde se lze zapojit s vlastní invencí, jde buď o události, virtuální metody, nebo adapter. Modře jsou vyznačeny interface pro implementaci dané funkčnosti a šedě jsou interní implementace ASP.NET.

Viz též

SQL Transakce + mýty – Slides, dema, záznam [SQL DevCon 2008]

Slides a dema z přednášky na konferenci SQL DevCon 2008:

Z přednášky byl pořizován záznam, který najdete na našem YouTube Channelu:

Výjimky „The I/O operation has been aborted…“ na IIS7

Nedávno se nám v IIS7 na serveru (Windows Server 2008 Standard x64 EN) začaly množit výjimky:

Exception information:
    Exception type: System.Runtime.InteropServices.COMException
    Exception message: The I/O operation has been aborted because of either a thread exit or
an application request. (Exception from HRESULT: 0x800703E3)

Nejdřív k výjimkám docházelo jen tak občas, ale vzestup počtu byl doslova raketový a naše aplikace se staly nepoužitelnými. Proč chyby vznikly nevíme, máme malé podezření na aktualizaci kb947562, ale situace se po jejím odinstalování nezlepšila.
Zdá se, že vyřešit popsaný problém pomohla změna nastavení Managed pipeline mode aplikačního poolu z „Integrated“ na „Classic“.

Nekonzistence vlastnosti Visible třídy System.Web.UI.Control

Vlastnost Visible třídy Control používáme k zobrazení a skrytí controlu ve stránce. Dokumentace říká něco mírně komplikovanějšího: Gets or sets a value that indicates whether a server control is rendered as UI on the page. Tato zdánlivá komplikovanost má zásadní význam. Getter property totiž vrací false, pokud je skrytý control nebo některý z jeho rodičů ve stromu controlů.
Z mého pohledu jde o dosti nezvyklé a vůči ostatním vlastnostem nekonzistentní chování. Neočekával bych, že po nastavení vlastnosti na true budu číst false. Doporučuji tedy s vlastností Visible pracovat náležitě opatrně.

Příklad

Mějme dva panely (PrvniPanel a DruhyPanel), přičemž chceme, aby byl vidět právě jeden z nich. Oba panely jsou obaleny vnějším panelem.

<asp:Panel ID="VnejsiPanel" Visible="false" runat="server">
        <asp:Panel ID="PrvniPanel" runat="server">
        ...
        </asp:Panel>
        <asp:Panel ID="DruhyPanel" runat="server">
        ...
        </asp:Panel>
</asp:Panel>
PrvniPanel.Visible = true; // nějaký výraz, který tentokrát vrací true
DruhyPanel.Visible = !PrvniPanel.Visible
VnejsiPanel.Visible = true;
  • Na řádku 1 nastavíme první panel k zobrazení.
  • Na řádku 2 přečteme property PrvniPanel.Visible. Ačkoliv jsme ji na řádku 1 nastavili na true, vrací false, neboť rodič VnejsiPanel ve stromu controlů je skrytý. I druhému panelu tedy nastavíme Visible na true.
  • Na řádku 3 nastavíme vnější panel k zobrazení.
  • Postupně jsme všem panelům nastavili Visible na true a bude tedy vidět vše, ačkoliv to tak na první pohled nevypadá.

Nekonzistence vlastnosti Visible třídy System.Web.UI.Control

 

Vlastnost Visible třídy Control používáme k zobrazení a skrytí controlu ve stránce. Dokumentace říká něco mírně komplikovanějšího: Gets or sets a value that indicates whether a server control is rendered as UI on the page. Tato zdánlivá komplikovanost má zásadní význam. Getter property totiž vrací false, pokud je skrytý control nebo některý z jeho rodičů ve stromu controlů.
Z mého pohledu jde o dosti nezvyklé a vůči ostatním vlastnostem nekonzistentní chování. Neočekával bych, že po nastavení vlastnosti na true budu číst false. Doporučuji tedy s vlastností Visible pracovat náležitě opatrně.

Příklad

Mějme dva panely (PrvniPanel a DruhyPanel), přičemž chceme, aby byl vidět právě jeden z nich. Oba panely jsou obaleny vnějším panelem.

<asp:Panel ID="VnejsiPanel" Visible="false" runat="server">
        <asp:Panel ID="PrvniPanel" runat="server">
        ...
        </asp:Panel>
        <asp:Panel ID="DruhyPanel" runat="server">
        ...
        </asp:Panel>
</asp:Panel>
PrvniPanel.Visible = true; // nějaký výraz, který tentokrát vrací true
DruhyPanel.Visible = !PrvniPanel.Visible
VnejsiPanel.Visible = true;
  • Na řádku 1 nastavíme první panel k zobrazení.
  • Na řádku 2 přečteme property PrvniPanel.Visible. Ačkoliv jsme ji na řádku 1 nastavili na true, vrací false, neboť rodič VnejsiPanel ve stromu controlů je skrytý. I druhému panelu tedy nastavíme Visible na true.
  • Na řádku 3 nastavíme vnější panel k zobrazení.
  • Postupně jsme všem panelům nastavili Visible na true a bude tedy vidět vše, ačkoliv to tak na první pohled nevypadá.