Monthly Archives: September 2007

MultiLine TextBox validálása

Aki próbálta már az asp:TextBox vezérlőt TextMode="MultiLine" üzemmódban használni bztosan hamar észrevette, hogy a MaxLength tulajdonság bizony nem működik. Ennek nagyon egyszerű oka van: a MultiLine hatására nem input type="text" kerül a HTML kódba, hanem textarea, ott pedig nincs ilyen tulajdonság.

Akkor hogyan tudom egyszerűen ellenőrizni és korlátozni a mező hosszát lehetőleg kliens oldalon? Természetesen validátorral, mégpedig RegularExpressionValidatorral, valahogy így:

    <asp:RegularExpressionValidator ID="revComment" runat="server" 
        ControlToValidate="txtComment"
        ErrorMessage="Min. 5, max. 10 karaktert lehet bele?rni!" 
        ValidationExpression="^[sS]{5,10}$" />

Segítség a krixkrax megértéséhez:

  • ^ = szöveg eleje
  • [] = karakter osztály
  • s = white space és új sor karakterek
  • S = nem white space karakterek
  • {n,m} = minimum n-szer, de maximum m-szer
  • $ = szöveg vége

 

Technorati tags: ,

Jogosultságosztás ACL-lel

Előzmény: telepítő alkalmazás jól működik angol Windowson, elszáll magyaron. Vajon mi lehet az oka? Némi búvárkodás után egyáltalán nem meglepő eredményre jutottam: a Felhasználók.

Ha jogosultságokat szeretnénk állítgatni egy mappán .NET-ből, akkor 2005 óta örülhetünk, mert a .NET 2.0 már támogatja hozzáférés szabályozási listák, azaz ACL-ek (Access Control List) kezelését. Rá is kattanhatunk rögtön a FileSystemAccessRule osztályra és nem lepődünk meg, hogy a konstruktor első paramétere egy SID, azaz security identifier. Nagyon szép, hogy a SID-ek leírására létezik egy SecurityIdentifier osztály a System.Security.Principal névtérben és milyen egyszerű a konstruktornak paraméterként megadni, hogy például a @"BUILTINUsers" csoportra vagyunk kíváncsiak. Király, hogy van BUILTIN, mert így nem kell bedrótoznunk a gépnevet, ám miközben ennek örülünk, sikerült bedrótoznunk a Users csoport nevét. És hasonlóan lehet például az Administrator vagy a Network Service fiókról is szó. Mi ezekben a közös? Hogy más operációs rendszereken máshogy hívják őket, konkrétabban van Rendszergazda, Network Service és vannak Felhasználók is.

Végignézve a bevezetőben említett kódot, azért dobott exceptiont, mert a Users csoport nem létezik magyar Windowson, ott ugyanis Felhasználóknak hívják. Most akkor drótozzuk be az összes lehetséges értéket?

A megoldás ennél azért szebb, köszönhetően annak, hogy bármennyire is azt szoktuk mondogatni, hogy a SID egyedi, valójában nem az. A minden gépen létező csoportoknak és felhasználóknak ún. well-known SID-jük van, azaz előre lehet tudni őket. A jó hír az, hogy létezik egy CreateWellKnownSid nevű Win32 API függvény, ami képes visszaadni ezeket az ismert SID-eket és hogy még szebb legyen a kép, ezt meg lehet hívni P/Invoke-kal .NET-ből, sőt mi több, a SecurityIdentifier osztály helyből képes erre, ha a WellKnownSidType paraméterezésű konstruktorát használjuk.

Ezek alapján tehát például így hozhatunk létre mappát úgy, hogy a Felhasználók csoportnak biztos Full Control joga legyen rajta:

    Directory.CreateDirectory( path );
    DirectoryInfo dirInfo = new DirectoryInfo( path );

    // @"BUILTINUsers"
    SecurityIdentifier sid = new SecurityIdentifier( WellKnownSidType.BuiltinUsersSid, null );

    FileSystemAccessRule ace = new FileSystemAccessRule( sid, FileSystemRights.FullControl, AccessControlType.Allow );

    DirectorySecurity acl = dirInfo.GetAccessControl();
    acl.AddAccessRule( ace );

    dirInfo.SetAccessControl( acl );

 

Technorati tags: , ,

Csak összedobom, összehúzom és kész. Kész?

Gyakran lehet olyasmit hallani, hogy a Visual Studioban csak létrehozunk egy új projektet, feldobáljuk az oldalra a vezérlőket és máris kész a webalkalmazásunk és úgy jó, ahogy van, mert a Studio, na az aztán király.

Íme egy rövid lista arról, hogy mit érdemes ellenőriznünk, mielőtt az újonnan létrehozott oldalunkat checkinelnénk:

  1. Forráskód
    1. Az oldalak forráskódja követi a fejlesztőcsoport által meghatározott struktúrát (pl. a megadott egyedi sablon alapján jött létre, minden using #region-ben stb.).
    2. A forráskód a fejlesztőcsoportban használt egységes formázási beállításokat követi (pl. tabulátorok, szóközök). Ha nem így lenne, javítható a Ctrl+A, CTRL+K, CTRL+D végignyomkodásával. A beállítások a VS Tools > Import and Export Settings varázslójával átvihetők egyik gépről a másikra.
    3. A forráskód kommenteket tartalmaz a fejlesztőcsoport által elfogadott formában (pl. angolul vagy magyarul). Minden osztály, metódus és tulajdonság előtt szerepel XML komment.
    4. A code behind nem tartalmaz olyan kódot, amit markupban egyszerűbben le lehet írni, például expressionökkel.
    5. A markup nem tartalmaz olyan kódot, ami az oldal logikai működését befolyásolja, annak a code behindban a helye.
    6. A kód nem tartalmaz olyan bedrótozott értékeket, amiknek konfigurációs állományban a helyük.
    7. A változók és vezérlők értelmesen el vannak nevezve.
    8. ViewState lehetőleg oldal szinten ki van kapcsolva.
    9. Session state lehetőleg oldal szinten ki van kapcsolva vagy legalább read only.
  2. Fordítás
    1. Az egész alkalmazás lefordul, nem csak az adott oldal.
    2. A fordító nem jelez sem Error, sem Warning hibát.
    3. A VS Code Analysis (FxCop) funkciója nem jelez hibát, vagy minden figyelmeztetés ellenőrzése és kezelése megtörtént a Suppress Message funkció segítségével.
  3. Futtatás
    1. Futtatás során nem keletkezik kezeletlen kivétel.
  4. Akadálymentesség
    1. Minden img elem tartalmaz alt attribútumot, ami lehetőség szerint ki van töltve – VS aláhúzza. Firefox esetén a title attribútumot is célszerű kitölteni.
    2. Minden Image kontrollnál meg van adva az AlternateText tulajdonság értéke vagy GenerateEmptyAlternateText=true.
    3. Űrlapok esetén a Label vezérlők AssociatedControlID tulajdonsága ki van töltve.
    4. Hosszabb űrlapok fieldsetek segítségével rövidebb részekre vannak tördelve, például így:
    5. <fieldset>
          <legend>Kapcsolat</legend>
          <asp:Label ID="lblName" runat="server" AssociatedControlID="txtName" Text="Név:" />
          <asp:TextBox ID="txtName" runat="server" />
      </fieldset>

    6. Nem szokványos elrendezésű űrlap esetén a vezérlők TabIndex tulajdonsága meg van adva.
    7. A vezérlők AccessKey tulajdonsága meg van adva és ez vizuálisan meg is jelenik az oldalon, például így:
    8. <asp:Label ID="lblName" runat="server" AssociatedControlID="txtName" Text="<u>N</u>év:" />
      <asp:TextBox ID="txtName" runat="server" AccessKey="N" />
      <asp:Button ID="btnGo" runat="server" Text="Mehet" AccessKey="M" ToolTip="Elküldi a megadott adatokat (ALT+M)." />

    9. Navigációs vezérlők SkipLinkText tulajdonsága legyen lokalizáltan kitöltve.
    10. Táblázatok esetén a table elem tartalmaz caption elemet és táblázatot generáló vezérlők esetén (Calendar, GridView, FormView, DetailsView) a Caption tulajdonság ki van töltve.
    11. Táblázatok fejléce a thead és th elemekkel van megkülönböztetve.
    12. Táblázatok "sor fejléc oszlopa" a th elemben a scope="col" attribútummal van megkülönböztetve, GridView esetén pedig a UseAccessibleHeader és RowHeaderColumn tulajdonság be van állítva.
    13. Táblázatok helyett div elemekkel történik az oldal elemeinek pozícionálása, a table elemmel csak táblázatot jelenítünk meg. A div elemek logikai sorrendben követik egymást és az oldal CSS nélkül is értelmesen használható.
    14. Az oldal struktúrájának megértését a heading elemek (h1..h6) segítik, címsorok kiemelése ezekkel történik.
    15. Minden gomb és vezérlő esetén meg van adva tooltip, ami értelmes, bővebb magyarázatot tartalmaz.
    16. Az oldal tökéletesen használható képek és CSS nélkül is.
    17. Visual Studio Tools > Check Accessibility nem talál hibát az oldalon.
  5. Szabványok
    1. Érvényes XHTML DOCTYPE tartozzon az oldalhoz – VS sablonok beteszik. Például:
    2. <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">

    3. Az oldal standard részei meglegyenek: html, head, title, body – VS sablonok beteszik.
    4. Az oldal gyökér eleme XHTML névtérre hivatkozzon – VS sablonok beteszik. Például:
    5. <html xmlns="http://www.w3.org/1999/xhtml" >

    6. Minden elem név kisbetűs – VS-ben beállítható, hogy így írja.
    7. Minden attribútum idézőjelek között van – VS így gyártja.
    8. Minden elemhez tartozik záró tag – VS aláhúzza, ha nem jó.
    9. Nincsenek egymást átfedő elemek – VS aláhúzza, ha nem jó.
    10. Nincs minimalizált attribútum, tehát például az alábbi nem jó – VS aláhúzza:
    11. <input type="checkbox" checked />

    12. A name helyett az id attribútum szerepel XHTML 1.0 Strict és 1.1 esetén.
    13. Szkript blokkok CDATA szekcióban vannak, és hogy minden böngésző megegye, még kommentezni is kell ezeket a sorokat, például így:
    14. <script type="text/javascript">
          /* <![CDATA[ */
              
              function DoWork()
              {
                  // TODO
              }
              
          /* ]]> */
      </script>

    15. Az oldal vizuális megjelenésének beállítása CSS stílusokkal történik, lehetőség szerint külső .css fájl segítségével. Az oldal tökéletesen használható CSS nélkül is.
    16. A VS szerint az oldal XHTML szempontból rendben van, azaz nincs Error vagy Warning az Error List ablakban. Ehhez be kell kapcsolni a validálást a Tools > Options > Text Editor > HTML > Validation ablakban – alapértelmezés szerint be van kapcsolva.
  6. Lokalizáció
    1. Az oldalon megjelenő összes felirat (pl. Text, AlternateTextCaption attribútumok stb.) erőforrás fájlból jön.
    2. Az oldalon megjelenő olyan feliratok, amik az alkalmazásban több helyen szerepelnek (pl. Mentés, Mégsem gomb felirata) globális erőforrás fájlból jön.
    3. Minden hibaüzenet erőforrás fájlból jön.
    4. Szövegek összefűzésénél a String.Format paramétereként CultureInfo meg van adva.
    5. Az erőforrás rekordok értelmesen el vannak nevezve (pl. nem Button1Resource).
    6. Lokális erőforrások használatakor a meta:resourcekey értéke lehetőség szerint egyezzen meg a vezérlő id-jával.

Most hirtelen felindulásból "csak" ennyi jutott eszembe. Ezek egy részére figyel a Studio, egy részére tud figyelmeztetni a Studio, a többségére viszont csak a fejlesztő tud figyelni. Számára pedig ez akkor nem lesz kínkeserves feladat, ha beépül a napi rutinba és megszokja, hogy például egy kép beszúrása csak akkor van kész, ha van hozzá alt is, vagy hogy addig nem lehet checkinelni, amíg az XHTML és accessibility ellenőrzéseket le nem futtatja. Az ellenőrzésekhez és a teszteléshez az IE Developer Toolbar szinte nélkülözhetetlen eszköz.

Biztos kifelejtettem sok fontos dolgot. Ha ilyen jutna eszedbe, írd meg légy szíves kommentben! Köszi!

 

Technorati tags: , , , ,

SharePoint backup PowerShellel

Nem sok olyan szörnyű dolog van az életben, mint egy korábban írt forráskódot újra elővenni, hogy valamit módosítsunk rajta. A dolog egy kicsit kellemesebb, ha a kódot nem más írta, de ha VB Scriptben van, akkor azt semmivel sem lehet ellensúlyozni!

Ma abba a problémába futottam bele, hogy egy korábban írt backup scriptet kellene frissíteni, ami a tanszéki Windows SharePoint Servicest menti le. Furdalt a kíváncsiság, hogyan lehetne megoldani a feladatot PowerShellel…

Először is be kell töltenünk a Microsoft.SharePoint.dll-t:

[system.reflection.assembly]::LoadWithPartialName( "Microsoft.SharePoint" )

Ha ez a válasz, akkor jó, a hallgatás hibát jelent 🙂

GAC    Version        Location
---    -------        --------
True   v2.0.50727     C:WINDOWSassemblyGAC_MSILMicrosoft.SharePoint12.0.0.0__71e9bce111e9429cMicrosoft.SharePo...

Kellene egy SPGlobalAdmin objektum:

$globaladmin = New-Object Microsoft.SharePoint.Administration.SPGlobalAdmin

Aki nem hiszi, hogy létrejött, csak írja be, hogy $globaladmin és valami hasonló lesz a válasz:

Config                         : Microsoft.SharePoint.Administration.SPGlobalConfig
Version                        : 12.0.0.4518
AllowUnsafeUpdates             : True
ApplicationPools               : {DefaultAppPool, Intranet Pool, SharePoint Central Administration v3, WSS Admin Pool}
AdminPortUrl                   : http://maffia:4444/
AdminPortApplicationPoolId     : SharePoint Central Administration v3
AdminPortIISInstanceId         : 201702596
VirtualServers                 : {MAFFIA, MAFFIA, 152.66.251.54, MAFFIA...}
VirtualServerNames             : {Intranet Web Site}
ConfigDatabase                 : Microsoft.SharePoint.Administration.SPConfigDatabase
ConfigDatabaseServer           : MAFFIA
ConfigDatabaseName             : IntranetConfigDB
UseNtAuthenticationForDatabase : True
ConfigDatabaseUser             :
UsageSettings                  : SPUsageSettings Parent=SPWebService Name=WSS_Administration
OutboundSmtpServer             : MAIL
MailFromAddress                : no-reply@aut.bme.hu
MailReplyToAddress             : no-reply@aut.bme.hu
MailCodePage                   : 0
AdminFormDigest                : 0xA2F82FA8DAE0854788585078B59D6C2AD84A69D5FFCC8ED01CC1430E1A597E5825B9889FC5D2871FA149
                                 4111C72B52F0D248D4ED812A175485F5AC15B5A0AF7F,10 Sep 2007 17:32:09 -0000
AccountCreationModeEnabled     : False
InstalledLanguages             : {Magyar}
ServerLanguage                 : Microsoft.SharePoint.SPLanguage
TimeZones                      : {39, 16, 15, 14...}
UseHostHeaderAsSiteName        : False

 Tegyük el a gyökér webhely címét egy változóba:

$url = "https://maffia"

Nyissuk meg a címen elérhető SPVirtualServer objektumot:

$vserver = $globaladmin.OpenVirtualServer( $url )

Nézzük meg, hogy ez mit tud:

PS C:> $vserver

IisWebSiteSettings         : Microsoft.SharePoint.Administration.SPIisSettings
WebApplication             : SPWebApplication Name=Intranet Web Site Parent=SPWebService
HostName                   : 152.66.251.54
Port                       : 80
Url                        : https://intranet/
CatchAccessDeniedException : False
Sites                      : {a7b2b582-2017-49a7-8524-873d4aec27ae, ec4d8bdb-1ce7-427e-a0f1-3c5a9fc813d0, 7dc69ef5-ae41
                             -4afa-94d6-7f1b933509af, 2e764d06-842c-45d4-be57-ce6f28c9d110...}
Config                     : Microsoft.SharePoint.Administration.SPVirtualServerConfig
IISInstanceId              : 2049022554
VirtualServerId            : 32895ea5-1dc1-47ba-b25f-d9371aa50c0e
Description                : Intranet Web Site
PresenceEnabled            : True
Version                    : 12.0.0.4518
State                      : Ready
ApplicationPoolId          : Intranet Site Pool
OutboundSmtpServer         : MAIL
MailFromAddress            : no-reply@aut.bme.hu
MailReplyToAddress         : no-reply@aut.bme.hu
MailCodePage               : 0
ContentDatabases           :

Kérdezzük meg, hogy ennek az objektumnak milyen tulajdonságai vannak:

PS C:> $vserver | Get-Member -memberType property

   TypeName: Microsoft.SharePoint.Administration.SPVirtualServer

Name                       MemberType Definition
----                       ---------- ----------
ApplicationPoolId          Property   System.String ApplicationPoolId {get;}
CatchAccessDeniedException Property   System.Boolean CatchAccessDeniedException {get;set;}
Config                     Property   Microsoft.SharePoint.Administration.SPVirtualServerConfig Config {get;}
ContentDatabases           Property   Microsoft.SharePoint.Administration.SPContentDatabaseCollection ContentDatabas...
Description                Property   System.String Description {get;}
HostName                   Property   System.String HostName {get;}
IISInstanceId              Property   System.Int32 IISInstanceId {get;}
IisWebSiteSettings         Property   Microsoft.SharePoint.Administration.SPIisSettings IisWebSiteSettings {get;}
MailCodePage               Property   System.Int32 MailCodePage {get;}
MailFromAddress            Property   System.String MailFromAddress {get;}
MailReplyToAddress         Property   System.String MailReplyToAddress {get;}
OutboundSmtpServer         Property   System.String OutboundSmtpServer {get;}
Port                       Property   System.Int32 Port {get;}
PresenceEnabled            Property   System.Boolean PresenceEnabled {get;}
Sites                      Property   Microsoft.SharePoint.Administration.SPSiteCollection Sites {get;}
State                      Property   Microsoft.SharePoint.Administration.SPVirtualServerState State {get;}
Url                        Property   System.Uri Url {get;}
Version                    Property   System.Version Version {get;}
VirtualServerId            Property   System.Guid VirtualServerId {get;}
WebApplication             Property   Microsoft.SharePoint.Administration.SPWebApplication WebApplication {get;}

A Sites tulajdonság érdekes számunkra, ugyanis az SPSiteCollection osztály tartalmaz egy Backup metódust és éppen arra van szükségünk. Megjegyzem az stsadm.exe is éppen ezt hívja. De előbb nézzük, mit tudunk a webhelyekről, pontosabban webhely gyűjteményekről, hiszen nem SPWeb, hanem SPSite objektumokkal dolgozunk. Bátran be lehet írni, hogy $vserver.Sites[0], hogy megnézzük, mit mond a PowerShell egy webhelyről és természetesen ezt is belecsövezhetjük a Get-Member pajtásba.

Kérhetünk egy átlátható listát a virtuális kiszolgálón található webhely gyűjteményekről:

PS C:> $vserver.Sites | Format-Table Url, RootWeb

Url                                                         RootWeb
---                                                         -------
https://intranet                                            BME AAIT Intranet
https://intranet/courses/dotnet                             Csoportwebhely
https://intranet/courses/portals                            Webportálok fejlesztése
https://intranet/courses/SzofTechBSc                        A Szoftvertechnikák (BSc) tárgy munkaterülete
https://intranet/projects/seagull                           Seagull Project
https://intranet/projects/vjt                               Csoportwebhely
https://intranet/projects/vmts                              Visual Modeling and Transformation System
https://intranet/sites/eBooks                               Elektronikus könyvtár
https://intranet/sites/mscorpevents                         Microsoft Nemzetközi Rendezvény Archívum
https://intranet/sites/msevents                             Microsoft Hazai Rendezvény Archívum

Ebből rögtön látszik, hogy egyesek lusták átnevezni a webhelyüket. (Egyébként van itt egy csalás, ugyanis a RootWeb egy SPWeb típusú objektum, nem csak egy string.) A rendszergazda-lét előnye, hogy az ember retorziókat is alkalmazhat, például nem menti le a hanyag gazdik webhelyeit:

PS C:> $vserver.Sites | Where-Object{ $_.RootWeb.Title -ne "Csoportwebhely"  } | Format-Table Url, RootWeb

Url                                                         RootWeb
---                                                         -------
https://intranet                                            BME AAIT Intranet
https://intranet/courses/portals                            Webportálok fejlesztése
https://intranet/courses/SzofTechBSc                        A Szoftvertechnikák (BSc) tárgy munkaterülete
https://intranet/projects/seagull                           Seagull Project
https://intranet/projects/vmts                              Visual Modeling and Transformation System
https://intranet/sites/eBooks                               Elektronikus könyvtár
https://intranet/sites/mscorpevents                         Microsoft Nemzetközi Rendezvény Archívum
https://intranet/sites/msevents                             Microsoft Hazai Rendezvény Archívum

Egyetlen webhelyet így menthetünk le:

$vserver.Sites.Backup( "https://intranet/projects/seagull", "E:Backupsseagull.backup", $true )

A hátralévő részt mindenki el tudja képzelni: ForEach-Object segítségével ciklusba zavarjuk a metódushívást vagy függvényt gyártunk az egészből.

Már játszom egy ideje a PowerShellel, de még mindig tudok lelkesedni érte. A Windows Workflow Foundation vagy a SharePoint ennyi idő után már nem mert a szemem elé kerülni 🙂

 

Technorati tags: , , ,

Team Explorer telepítés internetről

A Microsoft Regional Directors levelezőlistáján egyértelműen kiderült, hogy nem én vagyok az egyetlen, akit nagyon idegesít, hogy a VS Team Suite telepítésekor nem települ a Team Foundation Server eléréséhez szükséges Team Explorer kliens. Mi több, még a telepítő CD-n sincs rajta, hanem a Server telepítő médián kell keresgélni, ami persze további nehézség a telepítésnél.

Mindennek nagyon egyszerű oka van: nem készült el a szerver temék akkorra, amikor a cég kiadta a klienst. Van egy jó és egy rossz hírem ezzel kapcsolatban. A jó az, hogy a Visual Studio 2008 Team Foundation Server és a kliens valószínűleg egyszerre készül el és jelenik meg novemberben. A rossz pedig az, hogy három év alatt nem sikerült megugraniuk a fejlesztőknek a telepítőkészlet integrálását, így továbbra is külön kell telepítenünk a klienst. A sötét alagútban egyedül az jelenti a távoli fényt, hogy nagy valószínűséggel legalább egy telepítő médián megtaláljuk majd a két telepítőkészletet és az integráció a tervek szerint a Visual Studio 2008 utáni, "Rosario" kódnevű változatában megvalósul.

Mit tehetünk addig is az újonnan a csapatba kerülő fejlesztőkkel, milyen linkre irányítsuk őket a telepítéshez? Közvetlenül letölthető a Team Explorer kliens a Microsoft Download Centerből, pontosabban innen – sajnos csak CD image formátumban, de ez is jobb a semminél. Na de ki tud megjegyezni ilyen URL-t? Keresgéljünk hát a Team System MSDN oldalain (http://msdn.microsoft.com/teamsystem), majd ott kattintsünk a felső Download linkre. Itt a jobb hasáb tetején megtalálható a Visual Studio 2005 Team Explorer letöltésre mutató hivatkozás.

 

Konfig módosítás telepítőből

Kár szépíteni a dolgot, mindenki utál telepítőt írni az alkalmazásához. A telepítő készítés igen komoly versenyben van a doksi írással, vagy a projekt vezetői teendők közül az erőforrás- és határidő becsléssel, ha azt nézzük, egy átlag fejlesztő mennyire undorodik tőle.

Szerencsére vannak jó források a neten a témában, igen kiváló Scott Guthrie cikke a webalkalmazások telepítéséről. Benne van képregény formában minden, nem csak a varázslás, hanem a saját telepítő készítése is. Röviden összefoglalva, így készítünk saját telepítő osztályt:

  1. Készítünk egy saját osztályt, ami az Installer osztályból származik.
  2. Odaragasztjuk elé a [RunInstaller( true )] attribútumot.
  3. Felüldefiniáljuk a megfelelő metódusát, például az Installt.
    • Így adunk át neki paramétert a Setup projektből:

      /targetdir="[TARGETDIR]" /targetvdir="[TARGETVDIR]" /targetsite="[TARGETSITE]"

    • Így dolgozzuk fel a paramétert:

      string targetDir = this.Context.Parameters[ "targetdir" ];

    • Hiba esetén InstallExceptiont dobunk.

Ez mind szép és jó, még arra is találunk példát a cikkben, hogy hogyan módosítsuk a web.config fájlt kódból. A connection string jó példa.

Ha viszont már jobban utánaolvasunk, akkor szinte csak olyan példákat fogunk találni, például az ASP.NET QuickStartban, ami az appSettings szekció tartalmát módosítja. De mi van akkor, ha nekem nem egy webalkalmazásom van, hanem például egy Windows Service projekt konfig fájlját akarom módosítani? Egy Windows Service projektben nyilván használni fogom a VS kódgeneráló képességeit és a Project Properties ablakban hozom létre a beállításaimat, ami valami ehhez hasonló XML kódot fog eredményezni a .config fájlban egy MyService nevű projekt esetén:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>

    <configSections>
        <sectionGroup name="applicationSettings" 
                      type="System.Configuration.ApplicationSettingsGroup, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089" >
            <section name="MyService.Properties.Settings"
type="System.Configuration.ClientSettingsSection, System, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089"
requirePermission="false" /> </sectionGroup> </configSections> <applicationSettings> <!-- A Windows Service beallitasai --> <MyService.Properties.Settings> <setting name="InputFolderPath" serializeAs="String"> <value>C:ProgramDataBME AAITMyService</value> </setting> </MyService.Properties.Settings> </applicationSettings> </configuration>

A feladat pedig az, hogy az InputFolderPath beállítás értékét kell a telepítőnek beleírnia a MyService.exe.config állományba. Na erre valahogy nem találtam példát, és nem is sikerült egyszerűen megoldani:

    private static void WritePathToConfig( string targetFolder, string path )
    {
        string exePath = Path.Combine( targetFolder, "MyService.exe" );

        Configuration config = ConfigurationManager.OpenExeConfiguration( exePath );
        ClientSettingsSection section = 
          config.GetSection( @"applicationSettings/MyService.Properties.Settings" ) as ClientSettingsSection;
        section.SectionInformation.ForceSave = true;

        SettingElement element = section.Settings.Get( "InputFolderPath" );
        element.Value.ValueXml.InnerText = path;
        section.SectionInformation.ForceSave = true;

        config.Save();

        Properties.Settings.Default.Reload();
    }

Nem is bonyolult, csak szokatlan, hogy .NET-ben ennyit kell kódolni egy ilyen egyszerű feladathoz 🙂

 

Technorati tags: ,

Shell folders

Tegnap azzal a problémával találtam szembe magam, hogy nem tudom elérni az MVP profilom oldalát, akármit csinálok, mindig elszáll a webalkalmazás és szerver oldalon átirányít a nagyon sajnáljuk, de gáz van oldalra. Még a kezdőlap sem jött be. Miután ezt elég gyanúsnak találtam, megpróbáltam másik gépen és ott működött gond nélkül.

Hm, mi lehet a különbség két hasonló konfigurációjú és azonos böngésző verziójú gép között?

Például a korábban letárolt cookie-k! Nosza szabaduljunk meg a Microsoftos cookie-któl! Erre a funkcióra nincs menüpont az IE-ben, ezért elkezdtem keresgélni a Cookies mappát, amit Windows XP alatt nagyon egyszerűen meg lehetett találni itt.

C:Documents and Settings<felhasználónév>Cookies

Na de hol van mindez Vistán? Ilyen esetekben ahhoz a trükkhöz szoktam folyamodni, hogy parancssorban keresgélek a mappa régi helyén, a kompatibilitást ugyanis úgy oldotta meg a Microsoft, hogy NTFS junction pointokkal átirányította a régi mappákat az új helyükre. Ez gyönyörűen látszik parancssorban:

C:Usersbalassy> dir /asd

 Volume in drive C is System
 Volume Serial Number is 88AC-9731

 Directory of C:Usersbalassy

2006.12.11.  11:02    <JUNCTION>     Application Data [C:UsersbalassyAppDataRoaming]
2006.12.11.  11:02    <JUNCTION>     Cookies [C:UsersbalassyAppDataRoamingMicrosoftWindowsCookies]
2006.12.11.  11:02    <JUNCTION>     Local Settings [C:UsersbalassyAppDataLocal]
2006.12.11.  11:02    <JUNCTION>     My Documents [C:UsersbalassyDocuments]
2006.12.11.  11:02    <JUNCTION>     NetHood [C:UsersbalassyAppDataRoamingMicrosoftWindowsNetwork Shortcuts]
2006.12.11.  11:02    <JUNCTION>     PrintHood [C:UsersbalassyAppDataRoamingMicrosoftWindowsPrinter Shortcuts]
2006.12.11.  11:02    <JUNCTION>     Recent [C:UsersbalassyAppDataRoamingMicrosoftWindowsRecent]
2006.12.11.  11:02    <JUNCTION>     SendTo [C:UsersbalassyAppDataRoamingMicrosoftWindowsSendTo]
2006.12.11.  11:02    <JUNCTION>     Start Menu [C:UsersbalassyAppDataRoamingMicrosoftWindowsStart Menu]
2006.12.11.  11:02    <JUNCTION>     Templates [C:UsersbalassyAppDataRoamingMicrosoftWindowsTemplates]
               0 File(s)              0 bytes
              10 Dir(s)   4˙062˙240˙768 bytes free

Valljuk be, ezek valóban logikusabb útvonalak. Csakhogy már borzasztóan unom, hogy képtelen vagyok megjegyezni az új útvonalakat és mindig CMD-znem kell, ezért elkezdtem keresgélni, hogy van-e egyszerűbb megoldás. Ekkor találtam rá egy blogra, amiből kiderült, hogy elég a Start Menü -> Run parancsába ezt beírnom és máris jön a keresett mappa:

shell:cookies

Sőt, ez elég sok mappára működik, mi több, a többségére működött már XP-ben is! A teljesség és az archiválás kedvéért idemásolom az egész listát, megjegyezve, hogy a forrás szerint eredetileg Keith Miller Windows Shell MVP érdeme:

shell: parancsok Windows Vistán

  • shell:Common Programs
  • shell:GameTasks
  • shell:UserProfiles
  • shell:MyComputerFolder
  • shell:SyncSetupFolder
  • shell:DpapiKeys
  • shell:SamplePlaylists
  • shell:Favorites
  • shell:My Video
  • shell:SearchHomeFolder
  • shell:System
  • shell:CommonVideo
  • shell:SyncResultsFolder
  • shell:LocalizedResourcesDir
  • shell:Cookies
  • shell:Original Images
  • shell:CommonMusic
  • shell:My Pictures
  • shell:Cache
  • shell:Downloads
  • shell:CommonDownloads
  • shell:AppData
  • shell:SyncCenterFolder
  • shell:My Music
  • shell:ConflictFolder
  • shell:SavedGames
  • shell:InternetFolder
  • shell:Quick Launch
  • shell:SystemCertificates
  • shell:Contacts
  • shell:TreePropertiesFolder
  • shell:Profile
  • shell:Start Menu
  • shell:Common AppData
  • shell:PhotoAlbums
  • shell:ConnectionsFolder
  • shell:Administrative Tools
  • shell:PrintersFolder
  • shell:Default Gadgets
  • shell:ProgramFilesX86
  • shell:Searches
  • shell:Common Startup
  • shell:ControlPanelFolder
  • shell:SampleVideos
  • shell:SendTo
  • shell:ResourceDir
  • shell:ProgramFiles
  • shell:CredentialManager
  • shell:PrintHood
  • shell:MAPIFolder
  • shell:CD Burning
  • shell:AppUpdatesFolder
  • shell:Common Start Menu
  • shell:LocalAppDataLow
  • shell:Templates
  • shell:Gadgets
  • shell:Programs
  • shell:Recent
  • shell:SampleMusic
  • shell:Desktop
  • shell:CommonPictures
  • shell:RecycleBinFolder
  • shell:CryptoKeys
  • shell:Common Templates
  • shell:Startup
  • shell:Links
  • shell:OEM Links
  • shell:SamplePictures
  • shell:Common Desktop
  • shell:NetHood
  • shell:Games
  • shell:Common Administrative Tools
  • shell:NetworkPlacesFolder
  • shell:SystemX86
  • shell:History
  • shell:AddNewProgramsFolder
  • shell:Playlists
  • shell:ProgramFilesCommonX86
  • shell:PublicGameTasks
  • shell:ChangeRemoveProgramsFolder
  • shell:Public
  • shell:Common Documents
  • shell:CSCFolder
  • shell:Local AppData
  • shell:Windows
  • shell:UsersFilesFolder
  • shell:ProgramFilesCommon
  • shell:Fonts
  • shell:Personal

shell: parancsok Windows XP-n

  • shell:Common Programs
  • shell:Favorites
  • shell:My Video
  • shell:System
  • shell:CommonVideo
  • shell:LocalizedResourcesDir
  • shell:Cookies
  • shell:My Pictures
  • shell:Cache
  • shell:AppData
  • shell:My Music
  • shell:InternetFolder
  • shell:Profile
  • shell:Start Menu
  • shell:Common AppData
  • shell:ConnectionsFolder
  • shell:Administrative Tools
  • shell:PrintersFolder
  • shell:ProgramFiles
  • shell:Common Startup
  • shell:ControlPanelFolder
  • shell:SendTo
  • shell:ResourceDir
  • shell:ProgramFiles
  • shell:PrintHood
  • shell:CD Burning
  • shell:Common Start Menu
  • shell:Templates
  • shell:Programs
  • shell:Recent
  • shell:Desktop
  • shell:CommonPictures
  • shell:RecycleBinFolder
  • shell:Common Templates
  • shell:Startup
  • shell:Common Desktop
  • shell:NetHood
  • shell:Common Administrative Tools
  • shell:SystemX86
  • shell:History
  • shell:Common Documents
  • shell:Local AppData
  • shell:Windows
  • shell:Fonts
  • shell:Personal

Végül a válasz az eredeti kérdésre: Vistán a Cookies mappa a C:Users<felhasználónév>AppDataRoamingMicrosoftWindowsCookies útvonalon található és a microsoft.com-os sütik törlése nem segített az oldal elérésében 😦

 

Technorati tags: ,

Nyelvi szegénység

Elárasztanak a desktopok, már szinte mindent desktopnak hívunk – vagyis inkább az amerikaiak -, aminek köze van az asztalhoz vagy éppen nincs köze a hordozhatósághoz:

Itt van rögtön az íróasztal, ma már az is desktop. Pedig az eredetileg csak desk, aminek van egy teteje. Nem vagyok etimológus, de ezt úgy hívom: visszafertőződés.

A fertőzés eredete valószínűleg a desktop metaforában keresendő, amit a GUI-k hoztak a számítástechnika világába. Ennél a kifejezésnél el tudom fogadni a desk+top párosítást, hiszen pont az a lényeg, hogy az asztalt felülről nézzük, sőt csak az íróasztal teteje érdekes.

Innen válhatott önálló kifejezéssé a grafikus felhasználói felületek háttere, a legalsó szint, ami a metafora szerint az asztal teteje, azaz desk top. Magyarul Asztal, ami talán valóban jobban segíti a metafora megértését, mint a háttér.

Aztán desktopnak szokás hívni manapság az asztali számítógépeket is. Naná, hogy az asztal tetejére szokás tenni őket, bár sokan gyűlöljük, ha ott foglalja a helyet és ott kattog. Itt is történt egy nyelvi fertőzés, hiszen mi lett a desktop ellentéte: a laptop. Itt meg aztán pláne logikus lehetne, hogy az ember az öle tetejére teszi a hordozható számítógépeket és nem bele. Bár magyarul ugyan éppen az ölünkbe tesszük a dolgokat és nem rá… Innen egyenes út vezetett az asztali környezet, a desktop environment, sőt egyszerűen csak DE világába.

Szintén fertőzésnek hívom azt, hogy a billentyűzet+egér párosításokat is desktopnak titulálják, van már lézeres asztaltető, szórakoztató asztaltető, na és persze ergonómikus asztaltető. Nemrég kaptam egy SMS-t, amiben az volt, hogy "hétfőn viszek egy desktopot". Kénytelen voltam visszakérdezni, hogy pontosan miről is van szó…

És persze a dolog megállíthatatlan, itt van például a desktop publishing kifejezés, amit a Wictionary így definiál:

An advanced form of word processing which includes image processing.

Naná, hogy az íróasztalon, sőt annak a tetején szokás az ilyesfajta tevékenységeket végezni, de mitől lesz az advanced?

Állítom, hogy a magyar nyelvben több a lehetőség és a magyar ember is kreatívabb, mikor új szavakat keresünk vagy alkotunk. Hol van az angolban egy olyan, mint magyarul a rendületlenül? Klasszikus példa, de nagyon kifejező. Kár, hogy hagyjuk magunkat elhülyíteni és átvesszük az igénytelen kifejezéseket, ahelyett, hogy őriznénk azt a nyelvi kincset, amit csak egyetlen nemzet mondhat magának ezen a földön.

 

Technorati tags: