Tag Archives: Errors and Exceptions

HttpException: The Controls collection cannot be modified because the control contains code blocks

Tuto krásnou výjimku můžeme znenadání dostat (mimo jiné), pokud budeme v controlu <head runat=“server“> používat code-bloky, např.

<head runat="server">
    <title>HAVIT Goran</title>
    <link rel="stylesheet" type="text/css" href="~/templates/styles/havit.css" />
    <link rel="stylesheet" type="text/css" href="~/templates/styles/global.css" />
    <script type="text/javascript" src="<%= ResolveUrl("~/templates/scripts/HavitScripts.js") %>"></script>
    <asp:ContentPlaceHolder ID="HeadtailCPH" runat="server" />
</head>

Onen ďábelský blok <%= … %> nemusí zpočátku vůbec vadit, pokud však někdy později do stránky přidáme funkcionalitu, která by chtěla měnit Page.Header, např. umístíme do stránky control, který si bude chtít přilinkovat přes Header vlastní styly a skripty, pak budeme obšťastněni krásnou výjimkou System.Web.HttpException:

The Controls collection cannot be modified because the control contains code blocks (i.e. <% … %>).

…lepší je tedy code-bloky <% %>, resp. <%= %> v <head runat=“server“> nepoužívat (ještě lépe je nepoužívat vůbec) a nahradit je jiným způsobem. V tomto konkrétním případě třeba za <%# ResolveUrl(…) %> data-bindovací konstrukci (samozřejmě pak musíme volat Page.Header.DataBind()).

AJAX: Nefunkční validátory uvnitř UpdatePanelu

Microsoftu se podařil pozoruhodný kousek, standardní validátory ASP.NET 2.0 nefungují korektně uvnitř ajaxového UpdatePanelu – při změně obsahu panelu se původní validátory neodregistrují. Např. tak nefungují validátory v GridView editaci, ve wizzardech, atp. Obvykle vyskakuje krásná JScript chyba „null is null“.

Předchozí beta verze AJAXu to řešily upravenými verzemi validátorů, které korektně používaly ScriptManager ke své přeregistraci. V RTM verzi AJAXu však již tyto validátory nejsou a Microsoft se rozhodl, že je bude aktualizovat všem přes WindowsUpdate, nezávisle na AJAXu.

Ta horší zpráva je, že tak dosud neudělal, přestože AJAX už dávno releasoval.

…takže kdo nemá nervy čekat na opravené validátory, musí sám ručně (přes <tagMapping>) použít jejich aktualizované verze (nebo odtud), tak jak tomu bylo v betách.

Podivné chování session, přegenerovávání SessionID

V aplikaci je přihlašovací dialog. Zde by měla aplikace vytvořit session a poslat její identifikátor klientovi, což se stane.

Po přihlášení se zobrazí stránka obsahující frames, každý frame (a iframe) však znovu dostává jiný identifikátor session. To je špatné, protože každému frame je potom poslána jiný identifikátor session a tudíž má jeden uživatel více session.

Problém nenastane, pokud do přihlašovacího dialogu umístím kód:

Session["some_key"] = "some_value";
Session.Clear();

Trochu mě překvapuje, že session Session.Clear() je možné provést a je možné mít tedy prázdnou session. ASP.NET tedy pravděpodobně ruší session, pokud s ní nebylo pracováno (nebylo k ní přistoupeno).

Celý problém jsem vyřešil potomkem HttpApplication (Global.asax):

private void Application_PreRequestHandlerExecute(object sender, EventArgs e)
{
    // tento kod opravuje podivne chovani Session.
    if (Context.Session != null)
    {
        Context.Session[&quot;__Application_PreRequestHandlerExecute&quot;] = &quot;some_value&quot;;
        Context.Session.Remove(&quot;__Application_PreRequestHandlerExecute&quot;);
    }
}

BUG: MasterPage zobrazuje default hodnotu ContentPlaceHolderu a ignoruje Content

Narazil jsem na zajímavý bug v ASP.NET 2.0 (2.0.50727)…

Pokud v ContentPlaceHolderu definujeme default obsah a použijeme v něm ebedded code block (starý vnořený ASP-style blok kódu <% %>, ale i <%= %>), pak ASP.NET ignoruje Content definovaný v konkrétních stránkách a stále zobrazuje pouze default obsah z MasterPage.

...
<asp:ContentPlaceHolder ID="ContentPlaceHolder1" runat="server">
   <% %>   <-- už tohle vadí
   <%= "Tohle taky vadí" %>
   <%= ResolveUrl("~/takhle-na-to-asi-narazime/") %>
</asp:ContentPlaceHolder>
...

Zajímalo mě, kde je pravděpodobná příčina problému, takže jsem se díval, co z toho ASP.NET stvoří a jak se to liší od funkční podoby. Zásadní rozdíl je už v metodě __BuildControl, kde narozdíl od korektní podoby (ContentPlaceHolder1 s jedním Labelem):

private ContentPlaceHolder __BuildControlContentPlaceHolder1()
{
      ContentPlaceHolder holder1 = new ContentPlaceHolder();
      this.ContentPlaceHolder1 = holder1;
      holder1.ID = "ContentPlaceHolder1";
      if (base.ContentTemplates != null)
      {
            this.__Template_ContentPlaceHolder1 = (ITemplate) base.ContentTemplates["ContentPlaceHolder1"];
      }
      if (this.__Template_ContentPlaceHolder1 != null)
      {
            this.__Template_ContentPlaceHolder1.InstantiateIn(holder1);
            return holder1;
      }
      IParserAccessor accessor1 = holder1;
      accessor1.AddParsedSubObject(new LiteralControl("\r\n\t\t\t"));
      Label label1 = this.__BuildControlTest();
      accessor1.AddParsedSubObject(label1);
      accessor1.AddParsedSubObject(new LiteralControl("\r\n        "));
      return holder1;
}

…chybí řádek return holder1;

private ContentPlaceHolder __BuildControlContentPlaceHolder1()
{
      ContentPlaceHolder holder1 = new ContentPlaceHolder();
      this.ContentPlaceHolder1 = holder1;
      holder1.ID = "ContentPlaceHolder1";
      if (base.ContentTemplates != null)
      {
            this.__Template_ContentPlaceHolder1 = (ITemplate) base.ContentTemplates["ContentPlaceHolder1"];
      }
      if (this.__Template_ContentPlaceHolder1 != null)
      {
            this.__Template_ContentPlaceHolder1.InstantiateIn(holder1);
            // return holder1;  <-- pravděpodobně chybí
      }
      holder1.SetRenderMethodDelegate(new RenderMethod(this.__RenderContentPlaceHolder1));
      return holder1;
}
 
private void __RenderContentPlaceHolder1(HtmlTextWriter __w, Control parameterContainer)
{
      __w.Write("\r\n\t\t\t");
}

Jinak bug je již reportován v Microsoft Connect (Feedback center), můžete se připojit k hlasování…

V odesílaných mailech chybí háčky a čárky, někde samy mizí

Pozoruhodná situace může nastat, pokud explicitně nenastavíme encoding mailů odesílaných z ASP.NET aplikací (resp. obecně .NET aplikací).

Může se nám totiž stát, že aplikace, která na jednom serveru korektně odesílá maily, v pohodě s češtinou, po přesunu na server jiný (jinak nastavený), najednou posílá maily „napůl české“. Ono „napůl“ je na tom to nejzáludnější, zprávy totiž nechodí ve stylu rozsypaný čaj, jak to známe ze špatně nastaveného encodingu, nýbrž jsou ve zprávě odebrány háčky a čárky od většiny českých znaků (zůstává třeba á, í, é). Člověka tak hned nenapadne, v čem je problém a bádá někde mimo aplikaci.

…v mém konkrétním případě druhý server díky svému nastavení posílal zprávy v encodingu iso-8859-1 a sám (předpokládám CDO, ale nebádal jsem nad tím) si je upravoval na nejlépe čitelné.

Zásadně tedy vždy explicitně určovat encoding zpráv!!!

// v případě System.Web.Mail i System.Net.Mail
using (MailMessage mail = new MailMessage())
{
   mail.BodyEncoding = Encoding.GetEncoding("iso-8859-2");
   // System.Net.Mail.MailMessage má i SubjectEncoding
   ...
}

SmptMail.Send: The ‚SendUsing‘ configuration value is invalid.

Ač dokumentace tvrdí, že se standardně použije lokální SMTP server, přesto někdy problém odstraní nastavení:

SmtpMail.Server = "localhost";

…každopádně v .NET 2.0 je lepší použít mailování z namespace System.Net.

Dynamicky přidávané controly musí mít nastaveno ID, jinak jim blbne postback

Pokud do control-tree přidáváme dynamicky nějaké controly, které mají obsluhu postbacku (data nebo event), pak pokud těmto controlům explicitně nanastavíme nějaké ID, může se nám snadno stát, že postback nebude korektně vyhodnocen, např.:

  • Button, LinkButton, ImageButton nebudou emitovat události Click, Command, …,
  • inputové controly (TextBox, DropDownList, …) zapomenou přes roundtrip data,

…v zábavnějším případě se nám může stát, že postback není korektní jen u některých dynamický controlů a u některých se vyhodnotí správně (třeba pokud přidáváme řádky objednávky, tak nám data zapomíná jen poslední řádek).

Nevím, jestli je to bug, ale dělalo to už v .NET 1.1 a dělá to i v .NET 2.0.

Každopádně nastavením ID u dynamicky přidávaných controlů se těchto potíží zbavíme!

private void CreateControlsHiearchy()
{
   LinkButton lb = new LinkButton();
   lb.ID = "MyLB"; // <--- bez toho není jisté, že se nám bude Click korektně volat !!!
   lb.Click += ...
   ...
   Controls.Add(lb);
}

Jak umoudřit eventy po ENTER ve formuláři

Pokud na straně klienta odešleme formulář klávesou ENTER, pak máme-li na stránce jediný submit-prvek (tlačítko) a k tomu jediný input-prvek (TextBox), pak díky chování mnohých prohlížečů (včetně Internet Exploreru), nedojde k vyvolání serverové události Click submit-prvku, nýbrž proběhne jen hluchý postback.

Ošálit to lze přidáním dalšího skrytého TextBoxu:

<asp:TextBox ID="EmailTB" Runat="server"/>
<asp:TextBox ID="dummy" Style="display:none;" Runat="server"/>
<asp:LinkButton ID="SubscribeLB" Text="Přihlásit" Runat="server"/>

Souborový přístup ke složkám nadřazeným/sousedním webové aplikaci

Dejme tomu, že jsme v hostovaném prostředí a víme, že je na disku zhruba následující adresářová struktura:

<nevíme>/Zakaznik/
<nevíme>/Zakaznik/wwwroot/
<nevíme>/Zakaznik/data/

…a potřebujeme se z webové aplikace dostat na soubory ve složce ../data/.

Na problém narazíme, pokud bychom použili

 Server.MapPath("../data/cosi.xyz");
Server.MapPath("/../data/cosi.xyz");
Server.MapPath("~/../data/cosi.xyz");
 

…dostaneme výjimku HttpException: Cannot use a leading .. to exit above the top directory.

Pomoc je snadná, pokud máme na cílové místo opravdu přístupová práva, pak stačí použít:

 Path.Combine(Server.MapPath("/"), "../data/cosi.xyz")

…a jsme tam.

ExternalException: A generic error occurred in GDI+. při Image.Save()

Tuto krásnou výjimku dostaneme, pokud chceme Image ukládat do stejného souboru, z kterého byl načten. GDI+ to prostě nedovoluje.

Dá se to ale obejít například zkopírováním obrázku do nové instance:

Bitmap bitmap;
using (Image image = Image.FromFile(sourceFilename))
 {
   // načteme si obrázek do bitmapy, abychom mohli zavřít soubor
   bitmap = new Bitmap(image);
}
...
bitmap.Save(...); // tady už to nevadí, přetrhli jsme vazbu na soubor