[MSDN Dev days 2004] Wat is jou opgevallen

[Anoniem: 32767]

21 en 22 januari waren er weer de Developer Days van Microsoft in het Nederlands Congres Gebouw in den haag.

Connect with the vibe
Microsoft heeft grootse plannen met de verschillende softwareplatforms. In oktober zijn deze plannen voor het eerst aan het publiek gepresenteerd op de Professional Developers Conference (PDC 2003). Voor iedereen die daar niet bij kon zijn, is dit een unieke gelegenheid om de daar onthulde informatie alsnog te vernemen.

Maak kennis met Microsoft Windows “Longhorn”
Ontdek de verbluffende mogelijkheden van SQL Server “Yukon”, de database van de volgende generatie
Kijk in de toekomst van applicatie-ontwikkeling met Microsoft Visual Studio “Whidbey”
Kom alles te weten over de allernieuwste webservices en .NET
Leer hoe u met Visual Studio het meeste uit Longhorn en Yukon haalt
Krijg de beschikking over programma codes van Windows Longhorn, SQL Server Yukon, Visual Studio Whidbey en andere applicaties.
Let’s Code
Als ontwikkelaar, softwarearchitect, software-engineer, webontwikkelaar of decision maker op het gebied van softwareontwikkeling en –architectuur mag u de Microsoft Developer Days 2004 niet missen!

Codenaam: Longhorn
Longhorn is de codenaam voor de volgende grote release van Microsoft Windows®, waarvan de software op tal van punten ingrijpend is vernieuwd. Op de Microsoft Developer Days maakt u exclusief kennis met Longhorn en krijgt u inzage in het bouwen van applicaties met Longhorn. Klik hier voor meer informatie

De verbluffende mogelijkheden van Yukon, de database van de volgende generatie.
De volgende release van SQL Server heeft als codenaam Yukon. De verregaande XML-support en integratie van de CLR (Common Language Runtime) biedt verbluffende mogelijkheden. Het resultaat: een nieuwe standaard in programmeerbaarheid, schaalbaarheid, beschikbaarheid en business.

De toekomst van applicatieontwikkeling: Visual Studio Whidbey
Whidbey is de codenaam voor de volgende ASP.NET-release, DE toekomst van de applicatieontwikkeling! Het ASP.NET 2.0 team is er in geslaagd het aantal coderegels drastisch terug te brengen. Ontwikkel applicaties nu nog sneller dankzij verbeteringen op het gebied van master pages, membership, compilation, personalization en nog veel meer. Ontdek ook de innovatie in Visual C#®, Visual C++®, Visual Basic® en andere programmeertalen.

Alles over de allernieuwste webservices en .NET-software
Webservices zijn door de branche massaal gekozen als standaardinstrument om toepassingen, systemen en apparaten met elkaar te verbinden. Op de Microsoft Developer Days worden nieuwe mogelijkheden en geavanceerde infrastructuurtools onthuld. U komt te weten wat de allernieuwste webservices-specificaties zijn op het gebied van security en transactie en ziet zelf hoe u uw webservices met .NET op een hoger niveau brengt.

Ik vond ASP.NET 2.0 en Indigio (komt ook uit voor Windows XP) de meest interessante onderwerpen.

Indigio omdat je nu eindelijk 1 'ding' hebt om tegen aan te kletsen ipv van verschillende API's en keuze te moeten maken tussen COM+,DCOM, MSMSQ etc..

ASP.NET 2.0 omdat je steeds minder code hoeft te schrijven voor zaken die je voor elke website (intranet/extranet) gebruikt. Vooral webparts.

Zoals gebruikelijk kreeg elke bezoeker dit jaar ook weer een tas met "goodies" mee naar huis. Natuurlijk ook een setje cd's met daarop de beta van Visual Studio.NET Whidbey. Terwijl ik dit typ verloopt de installatie. Ik ga zometeen meteen met webparts aan de slag.

De nieuwe database server, Yukon, vond ik tegenvallen. Er is nu wel 100% support voor XML en OO maar of dit nu snel/af is als Yukon uitkomt denk ik niet.

Natuurlijk ben ik niet de enige tweaker die er bij was (mag ik toch wel vanuit gaan ). Wat vonden jullie het meest belangrijke van de DevDays?

[ Voor 4% gewijzigd door Anoniem: 32767 op 23-01-2004 10:41 ]

[P_de_B]

Indigo

lijkt heel veelbelovend te worden. Ik denk dat dit een hele goede vooruitgang is. A-synchrone communicatie en heel eenvoudig een beveiligde verbinding met een webserver leggen klinkt mij goed in de oren. De presentatie was wel heel theoretisch maar dat zal wel bij het onderwerp horen.

Yukon
Ik vond Yukon niet tegenvallen.
• Native support voor XML met schemainformatie! Je kunt zelfs indexen leggen op elements van een XML veld
• Verbeterde XML importmogelijkheden
• T-SQL uitbreiding om eenvoudig hierarchische structuren te 'selecten'
• CLR code in de db runnen. Heel eenvoudig om bijvoorbeeld een C# wordcount *) functie toe te voegen in de je SELECT statement:

code:

SELECT bla, wordcount(foo) from Tabel

waarbij 'wordcount' dus een heel eenvoudig te schrijven C# methode is.

• verbeterde support voor VS
• Virtual Tables om de status/performance etc. van je db te onderzoeken.

Overigens is het niet echt zo dat je OO ondersteuning hebt. In theorie kun je wel objecten opslaan maar van performance is dan geen sprake meer. Het wordt ook afgeraden. User defiend datatypes zijn voor primaire types (telefoonnr, sofinummer etc.) niet voor objecten. Daar zul je een echt OO database voor moeten hebben en niet een relationele


Avalon

Eindelijk echte scheiding tussen programmeur en UI-designer. Je kunt ook eenvoudig verschillende user interfaces op hetzelfde programma plakken. Dat XAML is behoorlijk krachtig. Gevaar is wel dat je moet uitkijken niet 'over the top' te gaan. Nadeel is ook nog dat het alleen op longhorn zal gaan werken.

Infopath/bizztalk

Hoewel Infopath wel intressant lijkt was de presentatie slecht. Niets van opgestoken.


WinFS

Er komt een relationele database die meta data over al je documenten opslaat. Dit lijkt mij persoonlijk geweldig. Als je bijvoorbeeld nu al je offertes in de directory offertes\klanten opslaat kun je niet eenvoudig alle offertes van hetzelfde product bij elkaar zien. Dit zal met WinFS wel moeten kunnen. Verschillende 'views' op je documenten.

Samenvattend denk ik dat MS op de goede weg is. Het is denk ik ook niet allemaal 'vaporware' omdat de meeste dingen al werden geshowed op de Technology Preview die al beschikbaar is.

Heeft iemand trouwens de slides ook online kunnen vinden?


^{*) Volgens de presentator van het Yukon gedeelte kost een wordcount functie in T-SQL minimaal 1000 regels. Dat lijkt me wel overdreven. Moet volgens mij wel in 10 kunnen, maar dat terzijde...}

[Anoniem: 34083]

Avalon
Zag er erg gaaf uit. Al krijg ik altijd een beetje tegenstrijdig gevoel bij de Demo's (filmpjes). Het ziet er weer veels te gelikt uit. Gelukkig wel gave dingen doen met de interface! En natuurlijk de kracht van een Win32 app en de flexibiliteit van een Browser app!

WinFS
Tja, het blijft natuurlijk NTFS, met daarop een relationele database. Al zijn de toepassingen wel geweldig. En het feit dat emails ook in WinFS worden opgeslagen maken het helemaal mooi. Snel zoeken naar de juiste documenten!

Indigo
Goede zet van Microsoft om alle communicatie methodes terug te brengen naar 1 systeem. Dus DCOM, COM+, Webservices, Remoting. Alles bij elkaar! Vet!

Yukon
De enige sessie die ik heb gevolgt over Yukon is die van Astrid. Erg cool hoe je inderdaad het db type XML hebt in Yukon. Al vond ik de sessie vrij rommelig. Jammer dat ik de overiges sessies niet heb gezien, maar dat was een kwestie van keuzes maken.

ASP 2.0
Eindelijk grids zoals in winforms, minder code (echt een volledige app laten zien zonder 1 regel code). Werken met een Master template wat betreft je design, Thema's gebruiken en natuurlijk Personalisation! We gaan een leuke tijd tegemoed!

[whoami]

Anoniem: 34083 schreef op 23 januari 2004 @ 11:47:
Indigo
Goede zet van Microsoft om alle communicatie methodes terug te brengen naar 1 systeem. Dus DCOM, COM+, Webservices, Remoting. Alles bij elkaar! Vet!

Bedoel je nu dat Indigo DCOM, COM+, Webservices en remoting gaat gaan vervangen? Lijkt me sterk....

[P_de_B]

Dat is wel uiteindelijk de bedoeling.

[Anoniem: 34083]

What is Microsoft Indigo?
Indigo is a set of .NET technologies for building and running connected systems.

Indigo is a new breed of communications infrastructure built around the Web services architecture. Advanced Web services support in Indigo provides secure, reliable, and transacted messaging along with interoperability. Indigo's service-oriented programming model is built on the .NET Framework and simplifies development of connected systems. Indigo unifies a broad array of distributed systems capabilities in a composable and extensible architecture, spanning transports, security systems, messaging patterns, encodings, network topologies, and hosting models. Indigo will be an integral capability of Windows "Longhorn" and will also be supported on Windows XP and Windows Server 2003.

Microsoft has also done significant work to integrate Indigo with existing Microsoft technologies for building distributed systems including COM+, MSMQ, and ASP.NET Web services. Applications built with those existing technologies can now be exposed as services without modification to the application. This infrastructure-level solution greatly assists developers in exposing existing applications as services. Indigo also provides simple and mechanical mechanisms to migrate applications that use .NET Remoting, ASP.NET Web services, and .NET Enterprise Services to natively use the Indigo programming model.

http://msdn.microsoft.com...nlong/html/indigofaq1.asp

[_Thanatos_]

Whidbey sprak mij heel erg aan. Dat wordt dus VS.NET 2004, voor de mensen die onder een steen geleefd hebben.

• Generics in C# die we van C++ en Java gewend zijn, zitten erin, maar dan goed, want de generieke klasses worden niet door de .NET compiler, maar door de JIT compiler gemaakt en levert dus minder code in de exe op. Bij de laatste sessie liet die vent ook zien dat je zelfs een generic type als generic type kunt meegeven, dus zoiets als
  C#:
  

  Hashtable<int,List<string>>

• ASP.NET exception catching is erg cool, waarbij VS bij een ASP.NET exception direct terug naar je code gaat en aanwijst waar het mis ging en mogelijke oplossingen aanbiedt.
• IntelliSense vind je nu *overal*. Dus ook in <%...%> blokken en misschien ook wel in clientside javascript (ga ik zo ff testen of dat zo is).
• Je kunt classes verdelen over meerdere files, partial types genoemd in C#, expanded types genoemd in VB.NET.
• ASP.NET "master pages". Hierbij maak je 1 pagina die de look&feel voor je website definieert. Alle andere pagina's inheriten hier dan weer van.

En ik ben vast nog tal van features vergeten die ook in dit lijstje moeten.

[ Voor 3% gewijzigd door _Thanatos_ op 23-01-2004 13:23 ]

[Anoniem: 14124]

Ik vond overall de dag tegenvallen. De eerste 2 presentaties 's ochtends waren een waterval aan verkooppraat, en we hadden moeite om onze aandacht erbij te houden en de ogen open.

Daarna de BizTalk gedaan, nog slechter. Geen overzicht op het scherm, een nerveuse slordige presentatie.

Daarna Yukon in de PWC zaal, .. ondanks dat het microfoontje geen zin had, vond ik het juist erg interessant. Veel features waar ik zeker nut in zie, oa virtual tables (gelet op performancetuning zeer belangrijk). Wat mindere features toch de XML en Objects storage functionaliteiten.

Ondanks dat er werd vermeld, dat een relationeel db model voor snelheid is, en object en xml juist niet, vond ik de snelheid dermate tegenvallen (icm met OPath + index) dat de bruikbaarheid hiervan mij behoorlijk klein is.

Whidbey (Witbier) .. .. mijn aandacht ging vooral uit naar de mooie interface van Longhorn, de functionaliteit die werd getoond vind ik nu niet echt slaan op de praktijk. Leuk al die losse building blocks, maar het blijft toch altijd weer maatwerk, niet iedereen maakt van die geocities websites zoals Microsoft liet zien

De goodies, ... kon die bounty niet groter?

[ Voor 17% gewijzigd door Anoniem: 14124 op 23-01-2004 13:30 ]

[P_de_B]

Anoniem: 14124 schreef op 23 januari 2004 @ 13:28:
Ondanks dat er werd vermeld, dat een relationeel db model voor snelheid is, en object en xml juist niet, vond ik de snelheid dermate tegenvallen (icm met OPath + index) dat de bruikbaarheid hiervan mij behoorlijk klein is.

Hoe bedoel je precies? Welke snelheid viel tegen?

edit:

inderdaad, voor zo'n bounty helemaal naar Den Haag....

[ Voor 9% gewijzigd door P_de_B op 23-01-2004 13:34 ]

[Anoniem: 14124]

P_de_B schreef op 23 januari 2004 @ 13:34:
[...]


Hoe bedoel je precies? Welke snelheid viel tegen?

edit:

inderdaad, voor zo'n bounty helemaal naar Den Haag....

Ik heb daarna nog de presentatie van Astrid gevolgd, waar dieper werd ingegaan op XQuery en OPath, en het zoeken in een xml document van 3mb met OPath duurde langer als 20 minuten.

[P_de_B]

Ah, ok. Die presentatie heb ik niet gezien, toen zat ik bij die slechte infopath presentatie.

Inderdaad 20 minuten is wel heel lang, ik ben benieuwd hoe dit in de definitieve versie uit zal pakken.

[whoami]

_Thanatos_ schreef op 23 januari 2004 @ 13:22:
[list]
• Generics in C# die we van C++ en Java gewend zijn, zitten erin, maar dan goed, want de generieke klasses worden niet door de .NET compiler, maar door de JIT compiler gemaakt en levert dus minder code in de exe op. Bij de laatste sessie liet die vent ook zien dat je zelfs een generic type als generic type kunt meegeven, dus zoiets als

C#:

Hashtable<int,List<string>>

Hoezo in Java? Zijn die in Java dan al geimplementeert?

• Je kunt classes verdelen over meerdere files, partial types genoemd in C#, expanded types genoemd in VB.NET.

Dat vind ik zelf niet zo boeiend, ik zie er geen voordeel in. Waarom zou je een class over meerdere files willen spreiden? 't Lijkt me dat dat alleen maar onoverzichtelijk wordt.

• ASP.NET "master pages". Hierbij maak je 1 pagina die de look&feel voor je website definieert. Alle andere pagina's inheriten hier dan weer van.

Dat is dan wel weer interessant, dan kunnen we in ASP.NET hetzelfde doen wat al eeuwen mogelijk was in Delphi, en in C# ook mogelijk is, nl. template-forms maken.

[Anoniem: 34083]

P_de_B schreef op 23 januari 2004 @ 13:44:
Ah, ok. Die presentatie heb ik niet gezien, toen zat ik bij die slechte infopath presentatie.

Inderdaad 20 minuten is wel heel lang, ik ben benieuwd hoe dit in de definitieve versie uit zal pakken.

Waarschijnlijk blijft dit hetzelfde. Astrid gaf zelf al aan dat je het ook niet moet gaan gebruiken om grote bestanden in op te slaan.

Overigens duurde het na het aanbrengen van een index nog maar 3 minuten.

[EfBe]

XML in yukon is voor de buhne, je hebt er in de praktijk weinig aan. Oracle heeft bv al 2 jaar dit soort XML ondersteuning maar je ziet dat niet veel mensen het gebruiken. Dit komt ook omdat XML qua interpretatie in code een inmense ramp is, tenzij je daar logica voor gaat gebruiken die al een conversie voor je maakt, wat inhoudt dat het geheel traag wordt.

Vroeger had je uniVerse, een post-relational database (nu van IBM), met tables in fields van een andere table, ong. het idee van xml fields in een table. Op zich leuk, maar in erg veel gevallen meer een last dan een lust.

Ik hoor niemand over de zaken die er echt toe doen mbt yukon:
(Engels, reactie van iemand op mn blog over Oracle, die diep in Yukon was gedoken)
1. It supports schemas independent of users; users can be granted various schema access
2. It supports snapshot MVCC, and a little better than Oracle does - while Oracle deals with versions on page level, MS SQL works with individual records. This means less data being copied when a record is being split
3. It supports synonyms
4. It supports UDTs. In the complete sense of 4GL languages - fields, methods and properties. It also allows, or course, CLR functions (scalar and table-valued), custom aggregate functions, stored procedures and triggers (both on DML and DDL statements). The promised optimizations in processing all those CLR stuff inside SQL queries are not ready yet, but I was looking to the pre-beta only, so I guess they will make it before the final MS SQL Server 9.0 is released.

Het geneuzel over XML overschaduwd de werkelijke parels in de nieuwe database, dat is erg jammer: XML demoot leuk, het is een buzzword en veel mensen snappen niets van UDT's, MVCC en synonyms en waarom die toch zo belangrijk zijn, maar geloof me: ze zijn 1000 keer belangrijker dan welk XML statement in Yukon dan ook.

[EfBe]

Dat vind ik zelf niet zo boeiend, ik zie er geen voordeel in. Waarom zou je een class over meerdere files willen spreiden? 't Lijkt me dat dat alleen maar onoverzichtelijk wordt.

Nou laten we beginnen met het feit dat het uberhaupt bezopen is dat je je code per FILE opsplitst. Je werkt met classes, niet met files, het is geen C. Omdat men toch voor per-file classes (je kunt meerdere classes in een file stoppen btw) is gekozen, loop je tegen de limit aan dat je met code generators (zoals bv de form designer) in dezelfde file moet poeren als waar de developer zn eigen code inprakt. Dit heeft gevolgen en we kennen de ellende allemaal.

Het is een uitkomst dat men nu EINDELIJK al in 2004! heeft ingezien dat OO code per class moet worden gezien en HOE dat is opgeslagen is totaal onbelangrijk. Dus of de code in 1, 2 of 200 files is opgesplitst dat doet er niet toe. (dat ze uberhaupt geen ondersteuning geven voor het direct ontwikkelen/saven in een database snap ik niet, maar dat terzijde) Je kunt met opgesplitste 'files' dus in de ene file je eigen code toevoegen en in de andere file code genereren. Dit is perfect, want je kunt code die je zelf schrijft behouden terwijl je opnieuw veel code van je class generereert door een generator.

EDIT:
Is de whidbey versie btw een ECHTE beta? of dezelfde alpha als bij de PDC? Bij mijn weten is de beta nl. nog niet gebuild. We (== alpha testers) konden afgelopen paar weken wel via terminal services testen op een bak in redmond maar beta bits zijn nog niet gebuild, ik vraag me dus af of dit een 'beta' is of dezelfde 'alpha'.

[ Voor 13% gewijzigd door EfBe op 23-01-2004 14:13 ]

[P_de_B]

#4 heb ik gedeeltelijk genoemd. CLR functies in de db kunnen in sommige gevallen echt een aanwinst zijn. Complete objecten (als UDT) opslaan werd duidelijk niet aangeraden. (bijv. een object 'klant' in een veld stoppen )

De custom aggregates is inderdaad wel gezegd, heel intressant.

De rest van de dingen zijn in de presentatie van gisteren niet naar voren gekomen. Ik denk dat je wel gelijk hebt dat gebruik van XML wel 'stoer' over komt.

[Anoniem: 14124]

EfBe schreef op 23 januari 2004 @ 14:11:
[...]

Nou laten we beginnen met het feit dat het uberhaupt bezopen is dat je je code per FILE opsplitst. Je werkt met classes, niet met files, het is geen C. Omdat men toch voor per-file classes (je kunt meerdere classes in een file stoppen btw) is gekozen, loop je tegen de limit aan dat je met code generators (zoals bv de form designer) in dezelfde file moet poeren als waar de developer zn eigen code inprakt. Dit heeft gevolgen en we kennen de ellende allemaal.

Het is een uitkomst dat men nu EINDELIJK al in 2004! heeft ingezien dat OO code per class moet worden gezien en HOE dat is opgeslagen is totaal onbelangrijk. Dus of de code in 1, 2 of 200 files is opgesplitst dat doet er niet toe. (dat ze uberhaupt geen ondersteuning geven voor het direct ontwikkelen/saven in een database snap ik niet, maar dat terzijde) Je kunt met opgesplitste 'files' dus in de ene file je eigen code toevoegen en in de andere file code genereren. Dit is perfect, want je kunt code die je zelf schrijft behouden terwijl je opnieuw veel code van je class generereert door een generator.

EDIT:
Is de whidbey versie btw een ECHTE beta? of dezelfde alpha als bij de PDC? Bij mijn weten is de beta nl. nog niet gebuild. We (== alpha testers) konden afgelopen paar weken wel via terminal services testen op een bak in redmond maar beta bits zijn nog niet gebuild, ik vraag me dus af of dit een 'beta' is of dezelfde 'alpha'.

Ik heb hem nog niet geinstalled, maar ik denk de alpha.. (pak even het cdtje) .. BUILD 30703.27

[_Thanatos_]

Hoezo in Java? Zijn die in Java dan al geimplementeert?

Ik ken geen Java, maar heb me laten vertellen dat die wel generics ondersteunt... als dat niet zo is dan neem ik dat uiteraard terug.

[.oisyn]

[quote]_Thanatos_ schreef op 23 januari 2004 @ 13:22:
• Generics in C# die we van C++ en Java gewend zijn

C++ templates zijn niet de generics zoals in java en .net

Wat mij het meest aansprak (hoewel ik er niet bij was ) is de nieuwe naadloze aansluiting tussen native C++ en .net. Met de nieuwe keywords en speciale pointer syntax kun je native en managed code compleet mixen. Je kon zo native classes overerven van managed classes en andersom, en je kon tegelijk gebruik maken van C++ templates en .net generics

Ik heb een presentatie gezien waarin ze Quake2 gingen compileren als managed code. Het enige wat ze hoefden te doen was de quake2 code omzetten naar gewone standaard C++ (het was C code, wat niet managed gecompiled kan worden). Dat hadden ze gedaan en het compileerde zonder fouten. En het liep echt soepel met de software renderer op een vrij hoge resolutie

Ik denk dat whidbey voor mij de eerste stap richting .net zal zijn. Zelf ben ik voornamelijk bezig met performance-critical applications zoals games, en ze hebben me echt getoond dat .net vrij snel kan zijn. Goed, ik zie het nog niet snel gebeuren dat games erin geprogrammeerd zullen worden (hell, PC development neemt sowieso af wat games betreft, ik zie dat nog wel uitsterven eigenlijk), of dat ik dat zou gaan doen, maar het gaat om het idee. Het zal niet al te lang meer duren voordat de meeste windows applicaties gewoon onder .net draaien, het heeft gewoon veel en veel meer potentie dan dat java ooit gehad heeft

Verder hoop ik dat de C++0x standaard snel wordt afgewerkt en dat ie ondersteund wordt door de nieuwe VC++ compiler, maar dat zie ik niet snel gebeuren (dat eerste dan, het VC++ devteam heeft al bewezen dat ze de community erg serieus nemen en dus staat standard conformance erg hoog op de lijst. Vrij onwaarschijnlijk dat het al in whidbey verwerkt wordt, ookal is die nog zwaar alpha)

[EfBe]

oisyn, maak je geen illusies mbt C++ op .NET: het blijft SI, andere templates en de mix van managed en non-managed code is wel voor het oog daar, maar je vergalloppeerd je snel wanneer je echte C++ templates gebruikt en MI en je wilt dat ineens managed gaan gebruiken, dat kan dan nl. niet.

Volgens lippman zijn ze nu wel bezig met een mix van MI in managed en nonmanaged maar dat is toekomstmuziek.

[pling]

Wat mij is opgevallen - en ik had er nog zo op gehoopt - was de grote afwezigheid van krachtige refactoring mogelijkheden in whidbey. Ik heb er in geen presentatie iets over gezien.

[EfBe]

Whidbey heeft die ook niet. Als je naar IntelliJ kijkt, wat al een tijdje beschikbaar is, dan verwacht je niet anders dan dat iig al die mogelijkheden in whidbey zitten, maar hte is slechts een fractie. Totaal onbegrijpelijk. Men zeurt er overigens al over hoor, dus wellicht worden ze uitgebreid, maar ik kan me niet aan de indruk onttrekken dat het team wat aan whidbey werkt erg klein is, te weinig resources heeft en te weinig tijd heeft gekregen. Het grootste software bedrijf ter wereld kan toch wel met een IDE op de proppen komen die IntelliJ verslaat!?, kennelijk niet.

[_Thanatos_]

Ik gok dat in dit draadje meer kennis is van whidbey (gezien iedereen hier die 8 CD's heeft gekregen ) dan op de rest van GoT. Misschien had ik dan ook deze twee kleine vraagjes beter hier kunnen posten...

[alienfruit]

Tja. Borland kon het ook niet Terwijl ze de knowledge wel in huis hebben, zie de refactoring in JBuilderX (werkt prima, imho) en overname van BoldSoft, TogetherSoft en Star*. Jammer dat ECO nog een trieste boel is op dit moment, het kan echt wel wat leuks worden uiteindelijk.

[Anoniem: 72194]

http://www.dev-itprodays.be
Ga je hier ook die cd krijgen?

Zou het de moeite zijn?

[flowerp]

EfBe schreef op 23 januari 2004 @ 18:37:
oisyn, maak je geen illusies mbt C++ op .NET:

Nou, maak je die illusie maar wel. De eerste C++/CLI (zoals je die nu in VC7.1 vindt) was een slechte grap, maar de nieuwe ECMA C++/CLI binding gaat dus echt wel heel groot worden. Het is inderdaad toekomst-muziek, maar geen vage toekomst. Er wordt nu heel hard en heel concreet aangewerkt. Deze nieuwe binding ondersteund wel 100% standard C++ op CLI alsmede vele mix vormen.

[EfBe]

flowerp schreef op 25 januari 2004 @ 15:41:
Nou, maak je die illusie maar wel. De eerste C++/CLI (zoals je die nu in VC7.1 vindt) was een slechte grap, maar de nieuwe ECMA C++/CLI binding gaat dus echt wel heel groot worden. Het is inderdaad toekomst-muziek, maar geen vage toekomst. Er wordt nu heel hard en heel concreet aangewerkt. Deze nieuwe binding ondersteund wel 100% standard C++ op CLI alsmede vele mix vormen.

Nee. CLI ondersteunt geen MI, MC++ ook niet. Nu niet, en als het aan MS ligt, nooit. Alle MI code is non-managed. Lippman zegt zelf dat ze werken aan een combinatie van managed en nonmanaged om MI te bouwen.

MI kan nl. niet in de huidige setup, want interop met C# bv zou dan niet werken. (heeft Eiffel ook last van).

[Anoniem: 103883]

Anoniem: 72194 schreef op 25 januari 2004 @ 09:58:
http://www.dev-itprodays.be
Ga je hier ook die cd krijgen?

Zou het de moeite zijn?

Jep, ik kan bevestigen dat dezelfde Whidbey CD's ook op de Belgische DevDays (eigenlijk Developer & IT Pro Days) aan de deelnemers gegeven zal worden.

Tom Mertens
MSDN Belux content master

[EfBe]

Anoniem: 103883 schreef op 26 januari 2004 @ 09:22:
[...]


Jep, ik kan bevestigen dat dezelfde Whidbey CD's ook op de Belgische DevDays (eigenlijk Developer & IT Pro Days) aan de deelnemers gegeven zal worden.

Tom Mertens
MSDN Belux content master

Ieks! MS leescht mee!

[Anoniem: 32767]

Vond het wel jammer dat we geen bits van Yukon mee kregen.

[pling]

Gelukkig komen er toch wat refactoring mogelijkheden in widbey, en nog wat krachtige ook, ben ik wel blij mee:

http://msdn.microsoft.com...bey_csharp_preview_topic4