Any more questions about ClickOnce?
ThomasAesir wrote:I reamember seeing a .Net Show video that touched a bit deployment models but I wanted them to get more into the nitty gritty.
As the writer of a deployment blog whose freetime is slowly increasing, would you be more interested in MSI information, VS Setup projects, or more forward looking info about ClickOnce and what we've got up our sleeve for Whidbey. I'm most knowledgable about the latter but I can put together some information from my team (who worked on VS Setup projects in 2002/2003) if you have MSI queries.
Deployment. Even if the framework were more widespread deployed what happens if a non-framework user tries run your .Net application? Are there any Installers that auto-magicly detect the missing framework?
I feel kind of silly promoting my own blog but:
I have a few posts on the new Whidbey generic bootstrapper that will allow you to install any components that you need (.Net framework included) as well as links to the Everett bootstrapper which will just install the framework if it's not installed already.
I'm surprised how many people don't realize that we (and by we I mean VB) have full generic support in Whidbey. We can consume, author, and use constraints. I just answered an internal email where someone was wondering how this all worked and I figured this info would be useful to all you Channel9 types.
Dim foo as New List(Of String)
Dim bar as New Dictionary(Of String, String)
Public Sub Foo(Of T)(ByVal param As T)
Public Sub Bar()
Dim x as String
' call explictly the one you want
' or let the compiler do it for you
Foo(x) ' same as above
Public Class Foo(Of G,E,N,E,R,I,C,S)
Public Class Foo(Of T As IEnumerable)
Happy Coding (especially if it's in VB )
Most of you probably saw the slashdot link yesterday but Chris has posted 2 *long* replies that really dig deep into a lot of the myths about Microsoft and Word.
Did you know that Word is binary backwards and forwards compatible starting with Word97? Have you seen the cool things that Word can do with XML in 2003?
A great blog entry that lets you get past the myths about Office.
I'm not on the ASP .Net team but I am on the VB team. Anything I say on this, though, is pure speculation.
VS is a complex eco-system. Something that seems simple to fix from the outside may not be that way on the inside and things that look complex can be really tough to change. Also, since every version of VS .Net targets the same version of the CLR that it shipped with and only that version, we have available all the new whiz-bang features of the CLR as well as access to all the work done by other teams (if ASP .Net writes a cool uploading subsystem that handles http, ftp, unc, local, etc. and offers a nifty new browse dialog then other teams my use that component). VS is very interconnected and makes use of MS development technology pretty extensively.
What I'm getting at is you don't know how many of these new features the improvements in HTML formatting used. If it's written in managed code (which I would guess that it is) then it could use generics, anonymous methods, different access level properties, etc. Maybe it takes advantage of some new .Net libraries that are only in Whidbey. Porting it back to 2003 could not only be hard, it could be impossible.
Also, remember that at the end of the day we are selling a product and we have to get that out the door. If the ASP .Net team took a month and back ported this feature then they would either start slipping on our release date or be forced to drop features from Whidbey. Also, the more features we backport the less incentive people have to move up to Whidbey. If we backported this (assuming it was possible) then the floodgates would open; why not backport Master Pages? Snap lines in winforms? DataGridView?
I think that everyone wins if we backport the critical stuff but focus on getting the next version out the door. I don't make these kinds of decisions but this seems to be feature level work rather than a bug fix and features usually belong in new versions.
Given how much public confusion arises from Microsoft Code names, imagine how much internal confusion there is!
Some projects have 2 or 3 names that they go by. Sometimes it's an old code name (such as Everett for VS 2003), the official name (VS2k3), or non-official version number (VS7.1). Of course, by the time we RTM we have an official external name (VS 2003 in our case) but that doesn't kill off the multitude of internal names for the project.
So if you think you've got it bad!