|
Windows Vista's EULA has a clause like this:
"9. MICROSOFT .NET BENCHMARK TESTING. The software includes one or more components of the .NET Framework 3.0 (".NET Components"). You may conduct internal benchmark testing of those components. You may disclose the results of any benchmark test of those components, provided that you comply with the conditions set forth at http://go.microsoft/fwlink/?LinkID=66406. Notwithstanding any other agreement you may have with Microsoft, if you disclose such benchmark test results, Microsoft shall have the right to disclose the results of benchmark tests it conducts of your products that compete with the applicable .NET Component, provided it complies with the same conditions set forth at http://go.microsoft.com/fwlink/?LinkID=66406."
Some people have been deliberately misinterpreting[^] this and crying censorship, even though this is obviously just a reminder of common sense rules: when you're publicizing benchmarks for someone else's products, you have to be responsible and disclose all of the relevant information.
It's probably in response to all the crap rival companies like Sony are flinging at Microsoft.
But anyway, .NET 3.0 and .NET 2.0 are supposedly separate products; .NET 3.0 isn't an upgrade to .NET 2.0. So does that mean these terms don't apply to .NET 2.0, where the majority of performance critical code is?
Uh oh.
|
|
|
|
|
So I got saw this in the CP Daily Insider today:
http://www.redmondmag.com/features/article.asp?EditorialsID=640[^]
One of the most innovative features coming in Windows "Longhorn" Server isn't really a feature as much as a whole new version of Windows. It's called Server Core, and it will only take one-sixth of the disk space of a normal Longhorn installation. It's not expected to need anywhere near as many patches and hotfixes as Windows 2000. It's a version of Windows that does not, in fact, use windows. It's breaking Microsoft's long-standing reliance on graphical interfaces and shaking things up in several of Microsoft's product groups.
Awesome so far. A dream come true for people like me.
Server Core can only act as a file server, domain controller, DNS server or DHCP server.
Cool, file server. Wait. "File server"? Not "Web server"? And then the truth hits hard:
<big>There's also no Microsoft .NET Framework.</big>
No .NET! Can you believe it?! They couldn't make a Web server for Server Core because they couldn't get ASP.NET working! So they had to settle with a (pfft) "file server". And why? Well, here:
This means you can't run any managed code on Server Core. Mason says his development team wants to add the .NET Framework to Server Core, but they first need the Framework team to modularize the code so they can add just the essentials.
Ouch...
.NET 1.1 and 2.0 are modular and very portable for the most part -- .NET 1.1 and 2.0 work on the PocketPC/Smartphone (Compact Framework), Xbox 360 (XNA), and of course, Win32. Heck, .NET 1.1 even compiles and works on FreeBSD and OS X.
Not so anymore: remember, Server Core is Longhorn after all. But they couldn't possibly put .NET 3.0 on it. And so, Server Core's .NET implementation would be damned to either .NET 2.0 or to skip to 3.5 despite the lack of 3.0. Now what: a big huge mess. Customers have .NET 3.5 installed, but their .NET 3.5 programs won't run because they used an itty bitty class that came with .NET 3.0.
This is the exact worst case scenario that I was yelling about in the petition:
2. “Bootstraps” – .NET 3.0 does not have a “bootstrap”. It offers libraries that provide functionality as needed (just as it’s always been for .NET applications), but the “bootstrap” is in fact the .NET 2.0 CLR; “.NET 3.0 applications” merely make use of its libraries. Not only is this misleading, <big>it impairs the modular paradigm of the .NET Framework</big>. In terms of “kernels” and “bootstraps” as in the Channel9 video, the microkernel structure of the .NET Framework has been traded for a monolithic kernel.
5. Non-Win32 (Microsoft and non-Microsoft) implementations – Other implementations of the .NET Framework, such as the Compact Framework, SPOT OS, Singularity and Mono will suffer from naming confusions. The CLR team took very, very careful steps to make sure the .NET Framework works on other platforms as well. Mangling the .NET framework with Win32 specific API breaks that, <big>isolating the entire framework to Windows</big>.
Most of the other teams are a lot more careful: the BCL and CLR are carefully designed to work on other platforms with minimal modification (take a look at System.IO -- it works seamlessly on Unix). The C# team made painstaking efforts to standardize the language and submit it to ECMA and later ISO. They even put everything Windows specific (except System.Windows.Forms) in its own namespace called Microsoft.Win32. All that has gone to waste.
I mean, I'm sure that's not the only modularity issue. I imagine there's some problems with the installers and the complicated way they use MSI scripts to register assemblies in the GAC and such.
But in either case, these such problems point to a single culprit: the .NET Framework management team. This seems to be the team that makes all of the decisions on what goes in and doesn't go in the framework. Jason Zander alone, as he says in his video, is the "approver[^]" of all breaking (or what he likes to call "red bit") changes to the framework, including the one to accept Marketing's idea for the horrible misnomer. The same team also seems to be the one in charge of determining the installation and distribution process.
It looks to me as if there's a fundamental flaw in the decision making within this team.
The concern on the part of the Server Core team was obviously that they could probably do ASPX 2.0, but ASPX 3.5 (or whatever the hell they're going to call it) would be way too risky as a lot of it may rely on .NET 3.0. Therefore, any up-to-date version of the .NET Framework is too risky to support on a server OS due to its lack of modularity and consequent potential for breakage.
Well, you could say, we can still have a Web server on Server Core. Apache works with the Unix Subsystem (formerly known as Services for Unix -- now that's a nice name change eh?), and the Unix Subsystem works on Server Core. But oh man, the irony!
I hate saying this. I really do. I hate being an a***hole. But you can tell from how passionate I've been about this whole thing that this is an exceptional case, so I will say it.
Microsoft, we told you so.
|
|
|
|
|
I don't think WinFX is the problem. WinFX is just a few additional assemblies. They would just not work on Server Core, like System.Drawing (GDI+) and System.Windows.Forms probably would not work.
But the .NET framework installation requires Internet Explorer - on a plain Windows 2000 without service packs, you first need to update IE. I think there are some dependencies to {Internet/Windows} explorer parts that really shouldn't be there.
And it has been that way since .NET 1.0, completely unrelated to WinFX.
|
|
|
|
|
Actually IE is needed for the System.Windows.Forms.WebBrowser class, which is actually a wrapper for the IE COM interfaces. That's why Win2k needs the updates first. It's only so that people using Forms applications aren't baffled as to why their programs throw exceptions right as they open browser controls.
The only really Windows specific components within the .NET framework up until 2.0 are Forms, Enterprise services and arguably Interop services, though this is debatable since Server Core is still Windows and Interop uses only rudimentary Windows components.
Meaning to say, .NET up until 2.0 is indeed quite modular and portable. It certainly isn't bad to the point where they'd have to omit the whole framework from such a crucial product because it'd take too long to port.
The problem with WinFX is rather that there's now a higher risk and/or perception of risk of people, including people within Microsoft, using .NET 3.0 components for latter versions of the framework. It's part of the previous version so it's only natural to make use of it. Put bluntly, it's a landmine.
Which is fine for things like Xbox 360, since you'd seldom be using .NET binaries compiled for Windows on the 360, but as for Windows binaries on Server Core, that'd likely happen every day.
PowerShell for instance would be a good example of something that might suddenly break in latter versions. What if the PowerShell team suddenly decides to make low-level support for CardSpace in the next version? It would break on Server Core, and they'd have to stop offering it as their primary/daily use shell, forcing the whole community to resort again to VBScript and cmd.exe, thus making all of the PowerShell scripts written for version 1 on Server Core unusable.
|
|
|
|
|
.NET 1.0 requires an IE update, too. System.Windows.Forms.WebBrowser was introduced in .NET 2.0. I assume some other parts of .NET depend on the Windows explorer or some other shell libraries (which are updated together with IE).
And there's no reason the non-GUI parts of .NET 3.0 should not work on Server Core.
I agree that naming WinFX .NET 3.0 is a bad choice, but I don't think WinFx makes .NET less modular.
|
|
|
|
|
Implementation wise, yes, there are a few other things that might, like the crypto services and maybe even System.Xml. But Microsoft does have managed versions of those, used by things like Rotor and Singularity (maybe not Rotor; I can't remember). Also, I'm pretty sure the high security package and MSXML can both be installed on Server Core.
There are a lot of non-GUI stuff in .NET 3.0 as well (which is why I brought up CardSpace), but in all likelihood, they depend on higher-up Win32 functionality that probably would't be implemented on Server Core.
This being due to the simple fact that WinFX was, until just a few months ago, being developed by its programmers with the assumption that it will only be running on XPSP2, Server 2003 and Vista.
The problem is more potential risk than immediate consequences, which in terms of business, is bad enough. I'm sure with a mess like .NET 3.0 in the framework, I'd be wary of using it until I sat down with the implementors and was personally convinced that it can be implemented in time for V1.
|
|
|
|
|
Here's my reply to Jason. Hopefully he won't just shoot back with random rhetoric this time.
Hi Jason,
Thank you for your detailed reply. Unfortunately, my main concerns have been completely evaded – you have not addressed or even mentioned them. I feel bad for having sent you such a lengthy email of complaint on a Friday, but please – read it through properly when you have the time.
It’s very important. There are things being said by your customers that you and your team, being so busy, might not have noticed at all.
> The CLR binding mechanism treats major.minor as distinct values for version binding. That means if we created a 2.x release with one installer, it would have to be installed side by side with 2.0 to work.
If major.minor denotes a distinct value, then as far as the runtime is concerned, the name 3.0 is just as different from 2.0 as is 2.1 or 2.5. So, .NET 2.0 and 3.0 would have to be installed regardless – this is how it was explained both in your C9 video and on your blog, and this is how it has been with .NET 1.0, 1.1 and 2.0. So why then would this be a reason to choose 3.0 over 2.x? This makes no sense. Am I missing something?
> We implemented side by side technology to help with versioning and application compatibility. Because of this, even if we were to name the version of the .NET FX with LINQ support 2.7, there would still be a new C# compiler with this build. You will have the same set of installer issues and multi-targeting of compilers.
Not quite. At the point that LINQ is released, it would make sense for the platform to also be called .NET 3.0 (no one ever said anything about 2.7). A C# 3.0 developer would be able to say quite simply when distributing or introducing a product, that the minimum requirement for his program is .NET 2.x. If he wanted to work with or share his code with another developer, he could then say that the LINQ compiler is required.
Yes I know C#’s version numbers technically are not synchronized with .NET’s nor is C# the only language for the platform, but please listen: it’s way too late to be saying that. 50% of the whole damn industry relies on this notion. One poor fellow is getting certification for C# 2.0 while 3.0 is being released with no C# 3.0 to go with it, putting a dent in his otherwise state-of-the-art resume. There is real damage happening as a result of this. Would you still say that the name WinFX is more confusing or even misleading than .NET 3.0?
> The use of V3 instead of V2 seems to indicate V2 is already obsolete. I understand your concern on this one and the type of confusion it could cause. I do worry about the counter issue: if major versions of the software come out now and in the future but we only change the minor version number, it belies the major investment and advancements we have made in the system and could lead those not as familiar with .NET as yourself to underestimate our commitment to the platform.
Again, the obsoleteness is a relatively minor point. More concerning is the issue of maturity: a minor version increment indicates a program’s maturation – this is something both developers and Joe Users understand. It makes the adoption of both 2.0 and 3.0 seem risky, whereas with a name like 2.1 or 2.5, there is much more confidence. In fact, minor version changes indicate necessary updates – a good thing for adoption, in this case.
No one ever said Microsoft should increment only the minor version; that is a straw man argument. The major version number should not be incremented this time. Next time, with C# 3.0, yes – it should be called .NET 3.0. I think we both know this.
Two releases later the major version number is still going to be 3 anyway, so why are you in such a rush to make that number bigger? I’m sure Anders Hejlsberg and the others in the team of people working on “.NET 3.5” are somewhat insulted that their achievements are worth only a .5, while this is worth a whole 1.0.
Though from a technical standpoint I do not like the idea of mangling two totally separate products, I can live with it. From a marketing perspective, however, the name .NET 3.0 is still much less effective than 2.1 or 2.5, and the name WinFX seems the most strategic for Windows’ interests. Deployment wise, combining WinFX and .NET is nice, but there is no reason for it to be 3.0 – it might as well be 2.x. And finally, business wise, in explaining what .NET is to customers and employers, the name 3.0 is an absolute bane. Shouldn’t this be of utmost concern to you as our vendors for software that we are using for serious business?
Please, please reconsider your priorities with a fresh mindset. Show us that Microsoft is still capable of listening and answering to our needs.
Thanks again,
Rei
|
|
|
|
|
Jason Zander replied to that email I sent him on Friday. I'm glad he responded, but to be honest, he's being way too evasive. Here's what he wrote:
Hello Rei – Thank you for your mail. I appreciate your feedback and passion on this subject. The .NET Framework has always provided rich feature support in several areas such as engine and base class libraries, web, presentation, data, xml, and networking (including web services). In each new release we strive to add additional support to match new standards and incorporate features our developers request to make their jobs easier. The main “pillars” in what we referred to as ‘WinFX’ historically represent advancements in several of these feature areas. For example, Windows Presentation Foundation provides a new presentation technology and Windows Communication Foundation provides advanced web services support. Windows Workflow and CardSpace add business process workflow and a new security identity system to the Framework. As such, we’ve always thought of these technologies as advances to the core .NET Framework and not simply an adjacent technology. Having two names for the technology has proven to be very confusing and hence we have always been on a path to figure out one name to advance. In the end we decided to continue the .NET brand, in which we have made a significant investment in since its release in 2001.
Given this as context, I do not think having both a .NET Framework and WinFX as separate entities will be clear since each new version of the framework support is advancing key feature areas. For example, as the industry advances the WS* protocols, what software would I install to get that support? Is it only in WinFX? Only in .NET Framework? Both? With our naming clarified, the answer will always be a latest version of the .NET Framework.
In reading through your feedback, I see a few specific concerns that center around the use of the major version number as an indicator for the CLR version. Using 2.1 or 2.5 would clearly indicate that both are based upon CLR 2.0. But let’s look at a couple of the related concerns you brought up:
• Why not create a brand new version and call it 2.1? The CLR binding mechanism treats major.minor as distinct values for version binding. That means if we created a 2.x release with one installer, it would have to be installed side by side with 2.0 to work. This solution creates a new set of work for everyone: new tools to target both 2.0 and 2.x, another full framework to deploy to end users and in the enterprise, etc. Our goal with using the base 2.0 engine is to not restart that clock and introduce a new version to have to target. Using 2.5 (your second option) is really the same as this one, but giving an allowance to a bigger version gap to help indicate the scope of the features added.
• Which version of C# do I use? We implemented side by side technology to help with versioning and application compatibility. Because of this, even if we were to name the version of the .NET FX with LINQ support 2.7, there would still be a new C# compiler with this build. You will have the same set of installer issues and multi-targeting of compilers.
• The use of V3 instead of V2 seems to indicate V2 is already obsolete. I understand your concern on this one and the type of confusion it could cause. I do worry about the counter issue: if major versions of the software come out now and in the future but we only change the minor version number, it belies the major investment and advancements we have made in the system and could lead those not as familiar with .NET as yourself to underestimate our commitment to the platform.
I’m sure you have already seen it, but I recorded a Channel 9 video in July to cover a lot of these topics which may be useful for review:
http://channel9.msdn.com/Showpost.aspx?postid=217428
Thanks again for your feedback and passion on this topic, and for using .NET! I hope I have been able to clarify some of our decision making process and rationale for the plan we are executing on.
Sincerely,
Jason Zander
|
|
|
|
|
So I emailed Microsoft last Friday: Brad Abrams, Adam Denning, S. Somasegar, and of course, Jason Zander. Here's what I wrote:
To the decision makers of the .NET Platform,
You may be aware of the recent insistence of your customers to reverse the decision to brand WinFX as “.NET 3.0”. The decision was made, as stated by Microsoft, by popular demand, and to increase the perceived value of the .NET Framework.
What we have found is that despite the statement that we as customers asked for this change, in reality, such a request does not come close to representing the demand of your customers. In fact, it goes against our wishes as it complicates the way we do business with our customers. So, here is what your customers are really saying.
I have written an open letter to Jason Zander in the form of an online petition at www.petitiononline.com/winfx/petition.html, and it has gathered much attention amongst developers and the IT community.
Chris Maunder, co-founder and chief editor of The Code Project, writes in the headlines of the Code Project Weekly Newsletter:
“I, and many others, are baffled by the name change of WinFX to .NET 3.0. The .NET 3.0 Framework runs on the .NET 2.0 runtime and uses C# 2.0/VB 8.0. When Visual Studio 2007 ("Orcas") comes out we will have the .NET Framework 3.5 running C# 3.0 / VB 9.0 on the 2.0 version of the CLR. Got it? Got it.”
Though Jason has explained in the past that the C# language version number is separate from the CLR version number, it has never been necessary to learn, install and use two versions of the same software at the same time, and so this concern is a valid one, and it is the one most expressed by the nearly 900 signers of the petition thus far:
105.
Joe Buffington
I totally agree. My customers are very confused.
354.
Jonathan Choy
WinFX is a Windows SDK component, not a .NET component, and its naming MUST be corrected to clarify this - the overly broad use of the .NET tag as a marketing device on marginally related server products has been backed out on current versions of the Microsoft product line; let's NOT go there again.
361.
Brian Tyler
WinFX is the successor to Win32, not to .NET 2.0
432.
Enoc Pardue
WinFX cannot run without the .NET 2.0 Framework. Therefore, it should not be called .NET 3.0.
438.
Sandeep Dath
This change is critical to ISVs who communicate with their clients about the nature and content of Microsoft technology
475.
Steve Hall
Trying to explain to managers why a developer/tester needs to learn C# 2.0 in order to use .NET 3.0 is absolutely ridiculous! This will encourage the thousands of Unix bigots throughout Silicon Valley to just boycott both until Microsoft "gets their releases syncrhonized". This marketing blunder is akin to "Classic Coke". Methinks .NET 4.0 will end up being .NET 3.5 with some minor changes, but WITHOUT WinFX... Microsoft seems to always be too stubborn to get it right once, until it get's it wrong at least twice...
478.
Troy DeMonbreun
In a nutshell, the confusion will damage ROI (yours and ours) & give fodder to anti - .NET "promoters"
593.
J Cardinal
I agree entirely and some of us have to roll out and explain these changes to our end users, if *we* as developers find this confusing I can only imagine the hassles upcoming.
608.
Patrick
I don't necessarily have a solution, but we are having the hardest time keeping up with it all and are beginning to move from 1.1 to 2 and it is becomming very clear that the frameworks are incrementing way faster than we can keep up.
624.
Bryan Cook
This will ultimately hurt .net adoption at the enterprise level. Senior IT decision makers will most likely get spooked by the (needless) revving of the framework between Vista and Orcas. If they're extensions to the library, publish them as such; name it 2.0 + WinFX or 2.1 to give it a good canonical name
644.
Scott Johnson
Making technology easy-to-understand to "non-techies" is one of my most difficult jobs. Please help clarify this issue.
697.
Brian Hickey
Stay with the API - The framework must be consistently and rationally versioned and not become some marketing platform.
715.
Jorin Slaybaugh
WinFX is simply an API, not to be confused with future framework versions. Do this and we are setting ourselves up for "Framework Hell" similar to the "DLL Hell" that the .NET framework was supposed to remedy. No one will understand what and how anything works and what it represents, and it will discourage adoption.
731.
Dario Djurica
It is to messy.
780.
Mike Dimmick
I'm already fielding questions from confused developers on CodeProject.com. Typical comment: 'I'm not going to move to .NET 2.0 now because .NET 3.0 is coming out soon, but we'll need to evaluate it first so I won't move for another year.' This decision could actually hinder adoption of the current released version, .NET Framework 2.0
Although we do appreciate an effort for simplicity, as Einstein would say, things shouldn't be made any more simple than they can be, and I don’t think that the people who suggested changing the name to .NET 3.0 thought much for Microsoft’s credibility. Many if not most of us feel that we are being lied to. It may be good marketing for the short term, but it is certainly not good PR – and right now, dear Microsoft, PR is more important.
The most popular solutions that your customers suggest are as follows:
1. Package .NET 2.0 and WinFX together as .NET 2.1: By not incrementing the major version number, you can restore proper order without jamming .NET’s semantics for every coming version, and avoid rendering the perception that .NET 2.0 is already obsolete. It will also make it unnecessary to deploy two installers.
2. Rename to .NET 2.5: It may be better than “.NET 2.1” in that it indicates a large advancement, while still building upon the success of the .NET framework and maturity of .NET 2.0 – maturity being very crucial for adoption, particularly in the enterprise market. The name .NET 3.0 casts doubt on the maturity of the .NET framework as a whole.
3. Revert to the name WinFX: Which is more in need of recognition as cutting edge software: Windows or .NET? The answer is obvious: Windows. Windows Vista is taking a lot of criticism right now due to the perception that there are no substantial technological advancements. WinFX is a name that counters this notion and communicates some of Windows’ most recent, unique and significant achievements. WinFX is by far the best collective name for WPF, WCF, WF and all of what used to be the Pillars of Longhorn. Windows should not be robbed of these titles.
The third solution is my preference as it builds on the Windows brand and prevents a very inappropriate merger, but any of the others would also be satisfactory. RC1 was released earlier this month and the product is, as indicated by Jason on his blog, still open for improvement based on feedback. We have seen plenty of times how agile Microsoft is in naming its software, and all things considered, it is not too late. Please consider. This is much more than a simple matter of naming.
I, with the rest of your customers, expect no less than a full response, best in the form of an action: reversal of the decision to entangle .NET and WinFX.
Sincerely,
Rei Miyasaka
|
|
|
|
|
I'm going to start tracking the WinFX reversal movement status here. The people at Microsoft have been kind enough to respond to my emails, and I'm sure some people are interested in reading the correspondence.
So far it's gotten around 890 signatures, and it's cast light on some really significant problems with the naming beyond just recognition or Mono/Compact Framework support.
August 9
Start of the petition against the decision by Microsoft to rename WinFX to .NET 3.0.
Read the petition here: http://www.petitiononline.com/winfx/petition.html[^]
August 23
Paul Krill of InfoWorld reported[^] on the petition. About 200 people signed in the couple days following.
September 1
Microsoft released .NET 3.0 RC1. Mixed feelings on this one... yay for RC1, boo for .NET 3.0.
September 18
Chris Maunder wrote about the name change and petition in the headlines of the Code Project weekly newsletter. Another 200 or so signatures in about one day.
-- modified at 6:17 Thursday 12th October, 2006
|
|
|
|
|
Have you abandoned this project? I don't see any activity for more that a year.
Thank you,
de
|
|
|
|
|
Somewhat. .NET 2.0 has an HTTP server class built in along with a lot of crucial features that I was hoping to implement, namely SSL. MiniHttpd was mainly intended for .NET 1.1.
Is there something I can help you with regarding MiniHttpd?
|
|
|
|
|
I hadn't seen any activity for a long time.
I've converted the project to .NET 2.0 and a bunch of things in the sample app broke - like the tree menu got unhooked from the tree and the actions all got unhooked from the menu items. Also, the classes (and properties) of the menubar and context menus have all changed so any minor change to the menus essentially means reworking the entire set.
The end result is that the tree is not updateing correctly and drag-drop was broken.
This had made it a bit difficult for me to "get the hang" of how to use the core stuff.
I am in the process of trying to straighten it out.
If I get stuck, I will post a question for you.
Thanks,
Dan Essin
|
|
|
|
|
Ahh that sucks.
I'm pretty busy right now, but if you still need help in a week or so, remind me and I'll try fixing the UI to work properly in .NET 2.0.
Rei
|
|
|
|
|
Thanks. I think I've mostly got it working. I've also added an embedded IE pane that I'm going to use to test the behavior of the server and put everything in a set of split containers to that it can all be resized.
I've also fixed up the links in the about form to use the 2.0 LinkLabel features.
I've also changed the logic for deciding which tree menu items to enable.
I'm curions about OnRootNodeChanged(). It is fired 2-3 times when the app starts up before the time when the real saved state has been deserialized. This doesn't appear to hurt anything but it seems a bit untidy. I'm not real familiar with the events that are generated by web servers so this may be unavoidable. On further study the extra events are comming from:
[Category("Directories"), Description("The type of the root folder, either a root folder or a drive on disk.")]
public DirectoryType RootType
{
get
{
return form.rootType;
}
set
{
form.rootType = value;
if(value == DirectoryType.Drive)
{
if(form.server.Root is VirtualDirectory)
{
BinaryFormatter formatter = new BinaryFormatter();
if(form.serializedVirtualRoot != null)
form.serializedVirtualRoot.Close();
form.serializedVirtualRoot = new MemoryStream(); formatter.Serialize(form.serializedVirtualRoot, form.server.Root);
}
form.server.Root = new AspxAppDirectory(form.rootPath);
//form.OnRootNodeChanged();
}
else
{
if(form.serializedVirtualRoot != null)
{
BinaryFormatter formatter = new BinaryFormatter();
form.serializedVirtualRoot.Seek(0, SeekOrigin.Begin);
form.server.Root = formatter.Deserialize(form.serializedVirtualRoot) as VirtualDirectory;
}
else
form.server.Root = new VirtualDirectory();
}
//form.OnRootNodeChanged();
}
}
Commenting out the 2 OnRootNodeChanged calls does not seem to impact the app. What do you think?
Dan
|
|
|
|
|
Hmm cool. I can't remember exactly, but I think the reasoning behind that was that the app should be in a working state even if the file didn't load properly.
You'll find that MiniHttpdApp isn't very optimized; I duct taped it together mainly as a sample application and to just share files on machines without IIS or Apache.
One thing that I've been wanting to work on is the serialization for virtual folders -- right now it just dumps a binary serialization text-encoded into an xml tag in the config file. It's not very robust. Xml serialization has improved a lot since .NET 2.0 though, so that might be interesting.
IE pane sounds nice too 
|
|
|
|
|
I could email you a copy of the project in its current state, if you like.
The browser pane could use some enhancement. Right now it just has a hard-coded button that navigates to the home of the web server and a back button.
Dan
|
|
|
|
|
Thanks, That would be great. I'm not sure when I'll be able to work on it enough to update the article but it would be nice to have.
My address is rei at (nospam) hotmail, minus the nospam and with the dot com.
|
|
|
|
|
I tried mailing you at hotmail but it bounced twice.
I simply cannot get the aspx part to work. This is what I tried to send before:
I'm a little confused about how to make the aspx server work.
I've created an asp web app that just displays some text. It works fine if I run it in debug mode within VS.
I've created a virtual directory and pointed it to the location of the aspx file and I've created a directory and dragged the apsx, web.config and .dll files into it.
Neither runs the page.
in the code:
protected override void SendFileOrIndex(HttpRequest request, IResource resource)
{
for(IResource current = resource; current != null; current = current.Parent)
{
if(current is AspxAppDirectory)
{
AspxAppDirectory app = current as AspxAppDirectory;
if(resource is DriveFile)
{
current is never and AspxAppDirectory
also there is an error on the default constructor for AspxAppDirectory. It does not call this(port) therefore the cascade of constructors is never invoked and the default.aspx never gets added to the list of default pages.
This means that even if current was an AspxAppDirectory, the default behavior part would never get invoked.
Some guidance would be greatly appreciated
Dan
|
|
|
|
|
type:
current is AspxAppDirectory is never true
Dan
|
|
|
|
|
ASPX can't be hosted in virtual directories, unfortunately. The ASPX engine requires actual directories to run under.
|
|
|
|
|
By the way, do you think you can try rei at (blabla) the fraser (yadda) dot com?
|
|
|
|
|
btw - IE does not seem to be able to open the pages served by this web server. It gives a "This page cannot be displayed" message. Firefox works perfectly.
Any thoughts?
Dan
|
|
|
|
|
Please ignore that last message. I found the cause of the problem.
Dan
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
