Programové nastavení UseUnsafeHeaderParsing

Vzhledem k častému rozpadání spojení při volání některých java webservices serverů je nutné buď vypnout keep alive nebo nastavit useUnsafeHeaderParsing. První metoda výrazným způsobem ovlivní výkon, protože se při každém requestu znovu navazuje tcp spojení, druhá se zase doporučuje pouze u „bezpečných“ serverů, u kterých nehrozí nebezpečí útoků pomocí přetečení bufferu.

V případě projektů, při kterých je i server v naší režii, je určitě lepší cesta nastavením useUnsafeHeaderParsing, to je možné jak v app.config, tak i programově pomocí reflexe:

Nastavení v app.config:

<system.net>
<settings>
<httpWebRequest useUnsafeHeaderParsing = "true"/>
</settings>
</system.net>

Programové nastavení pomocí reflexe:

[more]

public static bool SetAllowUnsafeHeaderParsing()
        {
            Assembly aNetAssembly = Assembly.GetAssembly(
              typeof(System.Net.Configuration.SettingsSection));
            if (aNetAssembly != null)
            {
                Type aSettingsType = aNetAssembly.GetType(
                  "System.Net.Configuration.SettingsSectionInternal");
                if (aSettingsType != null)
                {
                    object anInstance = aSettingsType.InvokeMember("Section",
                      BindingFlags.Static | BindingFlags.GetProperty
                      | BindingFlags.NonPublic, null, null, new object[] { });
                    if (anInstance != null)
                    {
                        FieldInfo aUseUnsafeHeaderParsing = aSettingsType.GetField(
                          "useUnsafeHeaderParsing",
                          BindingFlags.NonPublic | BindingFlags.Instance);
                        if (aUseUnsafeHeaderParsing != null)
                        {
                            aUseUnsafeHeaderParsing.SetValue(anInstance, true);
                            return true;
                        }
                    }
                }
            }
            return false;
        }

Více zde: http://msdn.microsoft.com/en-us/library/system.net.configuration.httpwebrequestelement.useunsafeheaderparsing.aspx

DirectorySearcher vrací maximálně 1000 záznamů

MSDN dokumentace neobsahuje příliš mnoho informací k tomuto problému, naštěstí v diskustní skupině to již někdo řešil.

Objekt DirectorySearcher obsahuje dvě klíčové vlastnosti:

PageSize – defaultně nastaveno na 0 – bez stránkování, určuje počet záznamů v jednom interním requestu na server, o „stránkování“ se stará sám objekt vyhledávače.

SizeLimit – defaultně 1000, maximální počet vrácených záznamů

Při defaultním nastavení nikdy nevrátí více než 1000 záznamů, protože v tom případě vyhledávač nestránkuje. Pokud jste si mysleli, že stačí SizeLimit změnit na vyšší hodnotu, tak jste se spletli. Snad jediná možná cesta je změnit PageSize, aby došlo ke stránkování, ale zde je další vtip dokumentace, nikde nenajdete, ze PageSize musí být z intervalu 0-1000 a už vůbec to, že pokud nastavíte hodnotu 1000, opět nedojde ke stránkování a DS vrátí pouze 1000 záznamů – to považuji snad za bug… Správna cesta je nastavit PageSize na menší hodnotu, například 999, následně již obdržíte záznamy všechny…

Příklad načtení všech uživatelů z LDAPu:

DirectorySearcher mySearcher = new DirectorySearcher(rootEntry);

mySearcher.Filter = "(&(objectCategory=Person)(objectClass=User))";
mySearcher.PropertiesToLoad.Add("cn");
mySearcher.PropertiesToLoad.Add("objectClass");
mySearcher.PropertiesToLoad.Add("sAMAccountName");
mySearcher.PageSize = 999;

SearchResultCollection mySearcherSearchResult = mySearcher.FindAll();

Zobrazení call stack při chybě

Sharepoint standardně při vzniku exception zobrazuje pouze její message, nikoliv i kompletní call stack, pro zobrazení všech detailů je potřeba modifikovat web.config následovně:

 

<customErrors mode="Off" />

<compilation debug="true">

 a ještě:

<SafeMode MaxControls="200" CallStack="true" DirectFileDependencies="10" TotalFileDependencies="50" AllowPageLevelTrace="false">

nebo ještě lepší způsob je mofikace systémovými prostředky Sharepointu, tedy prostředníctvím objektu SPWebConfigModification:

SPWebApplication webApp = siteCollection.WebApplication;
SPWebConfigModification callStackModification = 
     new SPWebConfigModification("CallStack", "configuration/SharePoint/SafeMode");
callStackModification.Value = "true";
callStackModification.Owner = typeof(Program).FullName;
callStackModification.Sequence = 0;
callStackModification.Type = 
     SPWebConfigModification.SPWebConfigModificationType.EnsureAttribute;
SPWebConfigModification customErrorsModification = 
     new SPWebConfigModification("mode", "configuration/system.web/customErrors");
customErrorsModification.Value = "Off";
customErrorsModification.Owner = typeof(Program).FullName;
customErrorsModification.Sequence = 1;
customErrorsModification.Type = 
     SPWebConfigModification.SPWebConfigModificationType.EnsureAttribute;
SPWebConfigModification debugModification = 
     new SPWebConfigModification("debug", "configuration/system.web/compilation");
debugModification.Value = "true";
debugModification.Owner = typeof(Program).FullName;
debugModification.Sequence = 2;
debugModification.Type = 
     SPWebConfigModification.SPWebConfigModificationType.EnsureAttribute;
webApp.WebConfigModifications.Add(callStackModification);
webApp.WebConfigModifications.Add(customErrorsModification);
webApp.WebConfigModifications.Add(debugModification);
webApp.Farm.Services.GetValue<SPWebService>().ApplyWebConfigModifications();
webApp.Update();

 

C# Script Engine – Aneb co command line neumí

Projekt C# Script Engine nepatří mezi nové projekty, ale za to velmi pozoruhodné. Spousty vývojářů řeší složité operace které jsou již mimo rozsah vlastností command line psaním vlastních aplikací, které není možné snadno editovat například u zákazníka. Přitom projekt CS Script (www.csscript.net) vše podstatné obsahuje.

  • scripty je možné psát ve všech CLS podporovaných jazycích
  • .NET 1.1 i 2.0 jsou podporovány
  • je možné vytvářet COM/WebService/Remoting proxy objekty za běhu
  • scripty mohou být zkompilované
  • script může importovat další script (pseudo include)
  • podporovány jsou všechny OS s .NET (Windows 98, ME, NT, 2000, XP and Windows Server 2003)

.NET COM Hell

Možná jste se již také řešili problém s volání COM objektů z .NET aplikace, wizardy a tutorialy vypadají moc pěkně a developer friendly, import COM objektů do referencí projektu klikací metodou je tak snadný, ale brzy každý narazí na problémy spojené se změnou rozhraní COM objektu, novou verzí atd. Před spuštění aplikace/aktivace assembly se provádí kontrola všech referencí a podreferencí projektu, v případě COM interop assembly se provádí kontrola shodné verze COM objektu pro kterou byl wrapper vytvořen – v tom je ale právě ten problém, pokud totiž voláte pouze jednu funkci, která se nemění, s další verzí COM objektu se celá aplikace která danou knihovnu používá nespustí (takže není možné například využívat COM objekty Office pro různé verze), ukončení aplikace není rovněž bezproblémové, protože se nedá nijak snadno zničit všechny reference na COM objekt i když voláte všude možně Marshal.ReleaseComObject (to je konkrétní případ pro Excelu)
Je tedy několik možností jak tento problém řešit:

[more]

  1. pro každou verzi vydávat service pack s novou verzí aplikace 🙁
  2. dynamicky generovat interop assembly a pak jí late bound užíva
  3. využít class RealProxy – Příklad užití je například v projektu SafeCOMWrapper

RealProxy
RealProxy je transparentní proxy kterou je možné řídit volání vzdálených objektů, překládá tak například volání funkcí klienta na specifické volání pro server (v tomto případě COM).

Základní předpokladem je znalost rozhraní serveru, pokud je DCOM server napsán v .NETu, je možné rozhraní vyextrahovat pomocí Reflectoru, v případě že je v C++ nebo jiném nativním jazyce, můžeme nejprve vytvořit interop assembly pomocí referencí ve Visual Studiu nebo příkazem tlbimp.exe a následně inteface přečíst pomocí Reflectoru.
Dostaneme tedy například:

public interface ICallMeCOM : IDisposable
{
    string HelloWorld(string sayThis);
    string HelloMessage { get; set; }
}

Teď zpět k projektu SafeCOMWrapper:
jedná se u ukázkovou implementaci možného využití RealProxy, v tomto referenčním projektu je navíc řešeno několik bugů jako například předávaní typu decimal referencí.
Kompletní tutorial najdete zde:
http://www.codeproject.com/csharp/SafeCOMWrapper.asp?df=100&amp;amp;forumid=195452&exp=0&select=1418263

Pokud do stejného projektu vložíte zdrojové soubory ze zmíněného odkazu, máte skoro vyhráno, nyní stačí jen objekt aktivovat:

ICallMeCOM callMe = (ICallMeCOM)COMWrapper.CreateInstance(Type.GetTypeFromProgID("PROGID-OBJEKTU"), typeof (ICallMeCOM));

Console.Write(callMe.HelloWorld("test"))

To je vše, jednoduché a spolehlivé 🙂