Slashdot Mirror

So that's the guy standing up in this picture! (note the url)

but a few are worth reading

I give you 7 of 9

I give you 7 of 9

They claim it isn't a marketting ploy, but right here, they paraphrase The Cluetrain Manifesto calling it the Channel 9 Doctrine. What a transparent grab for positive press. If they really wanted to "Learn by listening. When our customers speak, learn from them. Don't get defensive, don't argue for the sake of argument. Listen and take what benefits you to heart." Microsoft would have fixed the glaring security holes that the open source community has been pointing out for years a very long time ago. Instead, they keep opening up new ones.

http://blogs.msdn.com. Here you can find blogs from developers, tester, program managers, even MS job recruiters.

90% of these blogs are mostly junk (in my opinion) but a few are worth reading.

Check out the avatar for xpunkx. How long before Ashcroft scrambles to cover it up?

I give you 7 of 9

Why is this still listed as a beta? I thought it was the source of a finalized product that had already been used in multiple installations... Did I miss something?

The blog mentions that WiX has been used internally by several Microsoft teams. It most likely is in beta in a similar way to OSS projects such as Firefox, which are quite usable.

Their source code is in the SourceForge CVS. SF is taking a beating right now, but the developer mentions that it's in there on this site.

Actually, that isn't too far from the truth: http://blogs.msdn.com/robmen/archive/2004/04/05/10 7709.aspx

The developer has more information as to what WiX is in his blog:

http://blogs.msdn.com/robmen

Much more detailed information available at MSDN.

Instead you would more then likely have those scripts compiled and objects "loaded" on the fly using ICodeCompiler using the GenerateInMemory property set to true. You can then recompile this on the fly at any point.

That's the approach I was planning on using, however that just creates a more-or-less standard assembly in memory. There's no way to unload the assembly. Recompiling doesn't unload the old assembly, just returns you a reference to the new assembly via the CompiledAssembly property. The example you gave about recompiling Script A while Script B is instantiated isn't even an issue, since Script B doesn't overwrite Script A -- it co-exists with it in memory.

In an application it's expected that user supplied code can and will be changed and recompiled often; you'll quickly run out of memory as all those old and no-longer-needed assemblies start to add up.

Suzanne Cook, a developer of the CLR Loader, wrote up this blog entry on why unloading assemblies isn't supported in .NET, and pretty much any time it's brought up, Microsoft's response is basically "can't do it in our architecture, if cross-AppDomain calls are too slow, we'll work to speed them up" but they completely miss the constraint of not being able to pass parameters that you can't serialize across AppDomains.

Why doesn't C# support multiple inheritence?

The real problem is not so much that the Yukon date has slipped, it's that Whidbey (The next version of Visual Studio.NET and the .NET framework) is slipping with it. For who knows what reason, Microsoft decided that these products must be released together.

The reason they must ship together is because SQL Server is the guinea pig for Whidbey's new hosting interfaces (running an instance of the Framework inside your own non-managed application). This is not a trivial addition to the .NET Framework.

Check out this .NET architect's blog posting going briefly into some of the details of hosting and why SQL Server is so important to Whidbey.

david shapiro is listed as one of the patent applicants.

his blog is here
and his email address is danielsh@microsoft.com.

lets stop the speculating and just ask him.

I'm far from convinced that TDD is actually a good approach. Although it's pretty obvious that without testing the code is often trivially buggy, and unit testing is the cheapest way to perform testing. For instance this kind of thing is all too easy to do with TDD.

For unit tests you want to write your code, and then look at the best set of unit tests to do complete code coverage. For an OSS e3xample of that you can look at Vstr string library and the code coverage for that project.

In many cases, pseudo-compiled languages, or languages that use a VM are a better choice. No worrying about memory management, buffer overflows, etc.

There will always be a place for C and C++ in places where you *NEED* low-level control over things like memory management, or where performance is very critical. But for most applications, this is simply not the case. You want a language that can do all you need it to do, and you don't want to worry about the rest of the details.

For all the good that HTML is, developers and corporations alike want to do more.... a WHOLE lot more.

Exactly. Have a look at XAML, the new markup language for Longhorn.

It is intended to be used for both client-based and web-based programs. The integration with .NET will likely render it completely un-interoperable with Linux and the like, but there is a certain elegance in its design worth taking note of.

AT&T is the root of all evil