Maar nu niet meer

Ik sta er weer

Hieronder het antwoord van Nikhil zoals geplaatst op het asp.net forum:

This is going to be a short reply, until I can put out a better articulated blog post on the current status and what to look forward to in terms of new script# releases.

The project is not dead - just that its reached a temporary plateau of a stable release, with lots of teams using it successfully to get their job done. Yes, there are bugs, but I haven’t heard things that are fundamentally blocking from all the folks using it day to day. There are also some features people want, as well as things I’d like to get done, but that needs to be balanced with available resources.

There will be forthcoming releases. In fact just over the last couple of weeks I’ve been including a number of bug fixes for a release hopefully soon, my hope is before, but more realistically right after PDC. And then a subsequent quick turn around release adding support for all the new stuff added to asp.net ajax in 4.0.

Sorry for the lack of explicit updates… should have been messaged better. I was hoping for something more concrete to share than continually saying, yes, I am hoping for a new build in the Fall of ‘09

Thanks, Nikhil

Lees de voledige post hier.

Er zijn verschillende tools die helpen bij het migreren van SVN sources (inclusief historie) naar TFS. Hieronder staan er enkele:

Kyrosoft

Component Software

Wanneer je meer van dit soort tools kent, ik houd me aanbevolen.

Ik maak een pagina met daarop een Asp:FileUpload control , Asp:Image control en een submit button. Doel is, kies een bestand, druk op submit (ik krijg een PostBack), en de afbeelding wordt getoond. Het probleem is echter, ik heb geen mogelijkheid om de FileContent direct te koppelen aan een Asp:Image.

Om de afbeelding te koppelen aan het Asp:Image control moet ik het control voorzien van een url naar de afbeelding. De eerste gedachte is dat ik de afbeelding op schijf moet hebben. Ja, dat werkt natuurlijk. Maar dat wil ik niet.

Een andere oplossing is, in de PostBack de byte[] van de FileUpload op te slaan in een Session object onder een bepaalde naam. De ImageUrl van de Asp:Image laten wijzen naar een nieuw te maken aspx pagina laten wijzen (ShowImage.aspx).

Deze ShowImage.aspx heeft de volgende code in zijn aspx.cs:

protected void Page_Load(object sender, EventArgs e){
	Response.Clear();
	string sessionname = Request.QueryString["name"].ToString();
	if (!sessionname.IsNullOrEmpty())
	{
		byte[] bytes = Session[sessionname] as byte[];
		Response.BinaryWrite(bytes);
	}
	Response.End();
}

Dit heeft natuurlijk op deze wijze nogal wat security issues. Zo kan bijvoorbeeld een gogem figuur verschillende sessie waarden uitlezen. Deze zou je kunnen ondervangen door een wrapper object te maken met daarin de byte[] en specifiek in ShowImage.aspx uit te vragen of de sessie een object bevat van het wrapper Type.

- een image ‘databound’ maken aan een veld in een dataset

- meerdere embedded images toevoegen en op basis van een stuk VBScript code bepalen welke getoond moet worden

- een url opgeven, zodat het report de image gaat ophalen

- een parameter opgeven met de waarde van de image

- (vast nog wel meer …..)

Over de laatste wil ik het hebben: ‘een parameter opgeven met de waarde van de image’

Maak in je report een ‘parameter’ aan: Ga naar de ‘properties’ van je Report en kies : ‘ReportParameters’. Klik op de elipsis. Voeg een parameter toe, zoals op de afbeelding hieronder (de naam mag uiteraard anders zijn)

Ga terug naar je Report en sleep een ‘image’ item op je report surface.  Vul in de ‘properties’ van deze image de volgende gegevens in :

Bovenstaande zorgt ervoor dat de waarde die als parameter binnenkomt wordt vertaald naar een Byte[]. De ‘Source’ MOET op ‘Database’ staan. Een andere wijze lijkt niet te werken. Het gekozen MIMEType hoort eigenlijk te reageren op een stuk VBScript (dat nog niet is geschreven, maar dat komt nog wel) maar is voor nu hard op een PNG image gezet.

Belangrijk punt hier: de waarde die aan de parameter wordt meegegven is dus blijkbaar iets met ‘Base64′. Dit is een karakter-gebaseerde wijze van weergeven van bytes.

Stel je voor: voor dat de parameter wordt gevuld wordt er een plaatje gelezen en deze wordt van binair naar base64 geconverteerd. Dit gaat over de ‘lijn’. Het report zet dit weer om naar bytes en kan het weergeven.

Converteren van en naar Base64 gaat via: System.Convert.ToBase64String( <<byteArray>> ) en System.Convert.FromBase64String( <<base64String>> )

Om een cms systeem van een ontwikkelmachine naar een andere machine te plaatsen (bijvoorbeeld een test- of acceptatie machine), hoeven er slechts twee zaken te worden overgezet. De gehele folder van de webapplicatie binnen IIS, en de bijbehorende database.

In de IIS van de machine waar het deployed moet worden, maak je een nieuwe webapplicatie aan. Kopieer de inhoud van de ene IIS folder naar de ander….

Restore de backup van de ene database in de andere database, koppel een gebruiker aan de database en geef deze [owner] rechten.

Pas de web.config van de webapplicatie aan zodat deze wanneer die de database zoekt, uitkomt in de zojuist gerestorede database.

Controleer nog wel de schrijfrechten van ‘Network Services’ op een aantal specifieke mappen van Umbraco (config, css, data, media, xslt)

Voila!

Een site offline halen en op schijf zetten…..kan dus ook..alleen de inhoud van de map in IIS en een backup van de database.

(Haken en ogen zitten meer in de prerequisites van Umbraco (dotNet en dergelijke).

Check : http://code.msdn.microsoft.com/crmplugin

Zo’n import van customizations moest ik onlangs ook uitvoeren. Het lukte helaas niet. Was het bestand corrupt? Een duidelijke melding kreeg ik niet. Gelukkig bood de event viewer uitkomst door mij te voorzien van deze ‘warning’ van ASP.NET 2.0.50727.0:

Event code: 3004
Event message: Post size exceeded allowed limits.

Okay, het bestand dat ik wilde uploaden was bijna 10 Mb groot. De grootte van het bestand zou inderdaad best eens het probleem kunnen zijn. Op naar de web.config dan maar, normaal gesproken de plek waar je zoiets aanpast. En inderdaad.

Open de web.config van de CRM-server webapplicatie. Zoek op ‘httpRuntime‘. Wanneer je deze node gevonden hebt, zal je twee attributen aantreffen.

<httpRuntime executionTimeout=”300″ maxRequestLength=”8192″/>

De executionTimeout is de  instelling voor het aantal seconden dat een willekeurige http handeling door de server mag duren gemeten in seconden. De maxRequestLength geeft de maximale grootte aan in kilobytes van een te uploaden bestand. Ik verander de maxRequestLength in 10240 en ik kan mijn customizations.xml bestand van 10 Mb moeten inlezen. Voila.

Houd er rekening mee, dat er zich in de web.config meerdere httpRuntime secties kunnen bevinden. Bekijk de verschillende gevallen en bepaal keer op keer of je ze wil aanpassen of niet.

Het is aankomende 24 april weer de vierde donderdag van de maand. Een reguliere sessie met een niet zo reguliere gast. De avond wordt gehost door Sogyo en is zoals altijd weer gratis toegankelijk.

Wanneer je je wat meer wil inlezen bekijk dan in ieder geval de website van Jimmy Nilsson. Meld je in ieder geval aan voor zijn presentatie!