Nu..is niet meer dan het meest recente stukje geschiedenis.

Sinds een paar dagen schrijf ik mijn posts op http://www.dejongensvanwazzup.nl . Dit zal niet inhouden dat deze site uit de lucht gaat. Ik blijf namelijk een geliefde plek voor al die WordPress spammers. Heeft iemand nog wat pillen nodig? Controleer dan mijn advertenties hier aan de zijkant, regelmatig vind je -on-bruikbare links voor nepmedicijnen. Maar goed…

Het is stil aan de overkant

Maar nu niet meer

Ik sta er weer

Ronald Lemmen heeft me een link gestuurd met daarin verwijzingen naar een tweetal projecten die het leven en werken met Crm Customizations een stuk inzichtelijker maken.
Lees het artikel (de link van Ronald) hier: ISV Utilities for Comparing Customizations and Transferring Configuration Data.

Ik wil via een webpagina een bestand (afbeelding) uploaden en deze tonen zodra ik hem binnen heb.

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.

Om een dynamische (steeds wisselend) afbeelding op een report in Sql Server Reporting Services (SSRS) Report te plaatsen, zijn er verschillende mogelijkheden:

- 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 compleet content management systeem te installeren denk je al snel dat er veel voor nodig is. In het geval van Umbraco is niets minder waar.

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).

Bij een opdrachtgever begint binnenkort de migratie van onze sourcecode uit SVN naar hun TFS. Een manier die we kunnen hanteren is het plaatsen van de huidige code als beginpunt in het TFS. Dit zou er wel voor zorgen dat we geen geschiedenis van onze code meenemen (Je kan je afvragen of en hoe erg dit is per individueel geval).

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.

Velen onder jullie die de ontwikkelingen van Script# volgen zullen gemerkt hebben dat het nogal stil is van de zijde van Nikhil Kothari. Vragen worden inde community gesteld of het nog wel verstandig is om Script# te gebruiken met betrekking tot de ondersteuning van Nikhil. Op het asp.net forum is er nu wat duidelijkheid gekomen. Nikhil heeft hier zelfs zelf gereageerd -sinds lange tijd-. Bottom line, Script# is niet dood!

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.

In de Crm Sdk is een tool beschikbaar om een plugin te registreren (te koppelen aan entiteiten). Er bestaat echter een betere (en handiger) tool voor dit doel.

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