|
|
|
Posted
over 3 years
ago
by
nore...@blogger.com (Alex Yakunin)
I was returning to this issue for several times starting from this weekend. Initially it was looking really simple: by some reason our ASP.NET sample (as well as ASP.NET MVC and Astoria samples) were simply not working on 64-bit Windows Server 2008
... [More]
with IIS 7, although everything was fine on Vista. "Not working" means they were showing an error page on attempt to open any of these web application:
InvalidOperationException: Section 'Xtensive.Storage' is not found in application configuration file.
It was thrown by our own DomainConfiguration.Load(...) method - the following code there was throwing an exception:
var section = (ConfigurationSection) ConfigurationManager.GetSection(sectionName); if (section==null) throw new InvalidOperationException(string.Format( Strings.ExSectionIsNotFoundInApplicationConfigurationFile, sectionName));
So this was looking pretty simple: by some reason IIS does not see our section and thus returns null from GetSection method.
Certainly, initially I suspected there is something wrong with Web.config file. So I studied everything related to new configuration features that appeared in IIS 7. Nothing helped. I tried to rename this section, wrap it into group and so on. No results.
My Web.config was looking like that:
... <configSections> <section name="Xtensive.Storage" type="Xtensive.Storage.Configuration.Elements.ConfigurationSection, Xtensive.Storage, Version=1.0.0.0, Culture=neutral, PublicKeyToken=93a6c53d77a5296c"/> ... </configSections> ... <Xtensive.Storage> <domains> <domain name="mssql" upgradeMode="Recreate" connectionUrl="sqlserver://localhost/DO40-Tests"/> </domains> </Xtensive.Storage> ...
Btw, what was really strange is that actually IIS was seeing this section: when I tried to modify e.g. its name in <section name="..." .../> tag without modifying its tag names below, IIS was showing appropriate (different) error message. Moreover, running the same application under Visual Studio .NET (i.e. under integrated Cassini) on the same PC was leading to no errors!
Finally I found a workaround:
ConfigurationSection section; if (HttpContext.Current!=null) { // See http://code.google.com/p/dataobjectsdotnet/issues/detail?id=459 // (workaround for IIS 7 @ 64 bit Windows Server 2008) var config = WebConfigurationManager.OpenWebConfiguration("~"); section = (ConfigurationSection) config.GetSection(sectionName); } else section = (ConfigurationSection) ConfigurationManager.GetSection(sectionName); if (section==null) throw new InvalidOperationException(string.Format( Strings.ExSectionIsNotFoundInApplicationConfigurationFile, sectionName));
Can you imagine this?
Why default ConfigurationManager.GetSection does not work the same way in this case? Worse, why it does not fail at all on Vista, but fails only on 64-bit Windows Server 2008? Why, at least, it does not fail properly, with error like "you're using wrong method"? It behaves as if it deals with wrong .config file there.
I spent a lot of time on this mainly because I didn't expect there can be something related to API calls at all. All the problems I faced before on this OS were much more obvious. But in this case I was thinking there is really something wrong with Web.config content until I understood there can be an issue related to GetSection method we call. This was really not obvious for me, since the same code was working properly everywhere else.
Moreover, I couldn't find anything related to this issue on the web. I tried this workaround not because I found it somewhere, but because I found this part of API (I mean OpenWebConfiguration), and, btw, tried few other ways of its usage until it started to work, so possibly GetSection does not work properly not because it is buggy, but because WebConfigurationManager is buggy. Further I discovered there are some known bugs - e.g. I voted for this one. But as I said, I could find nothing exact.
So that's why I wrote this post. The issue seems important, since it is related to generally any web application using custom Web.config section. Of course, if it has any chance to run on 64-bit Windows.
P.S. This is the last bug related to running DataObjects.Net on 64-bit Windows I planned to fix till officially confirming "it works on 64-bit Windows" :) [Less]
|
|
Posted
over 3 years
ago
by
Dmitri Maximov
|
|
Posted
over 3 years
ago
by
Dmitri Maximov
|
|
Posted
over 3 years
ago
by
nore...@blogger.com (Alex Yakunin)
Recently I started paying much more attention to functional programming - this happened after a long talk with one really clever guy at our city's developers forum. Let's call him "Amateur Programmer" (this is his real nickname translation; I'll use
... [More]
"AP" to refer to him further). Certainly, he isn't amateur at all, moreover, he made few good talks at our users group. So... We've been discussing lots of topics related to software development in "is this good or bad" fashion, and our view was quite different on almost any different point. I'll list few examples:
I think granting the people a simple way of developing their own DSLs is generally bad. Not because DSLs are unnecessary, but because such an opportunity may lead to an explosion of count of DSLs in applications, and consequently, to explosion of count of absolutely crazy ways of writing programs (language design is complex!). So e.g. I don't pay much attention to Oslo's M, as well as JetBrains' MPS. Obviously, not because they're useless, but because they are intended for pretty small subset of developers and companies. In short, I like the beauty of C# (with lots of exceptions :) ), and generally I would prefer to avoid dealing with any home-made language. AP was strongly protecting DSLs. Side note: later I understood we're actually talking and even thinking about the same, but our origin points are different. So as it frequently happens, the truth was in the middle. I'm OOP fan. AP is FP (functional programming) fan; moreover, he generally exposed a point that OOP is wrong way of software development at all. That was pretty strange, because I knew he programs mainly on C#. On the other hand, my view on FP was nearly the following: "it must be used when it really matches the task best; but I can't admit I'd use it without OOP practices". Moreover, I clearly understand that e.g. concurrent programming is where FP looks is the best match. Side note: the same :)
There were other less interesting topics - e.g. we've been discussing RUP, UML, complexity of LINQ provider implementation and so on. What's the most important is that he gave a link to monadic parsers combinators in C#. I read this article and felt there is really something new for me. In fact, I felt there is a very generic concept (monad) I know almost nothing about. Moreover, we touched HaskellDB (AP's point was: HaskellDB is in fact, LINQ analogue in Haskell, and since it is just 200Kb, implementing LINQ translator must be much simpler in Haskell, so FP rules). What was really important for me here is that I discovered that Erik Meijer (known as architect of LINQ) was one of its co-authors - take a look at slide 6 here.
So this was enough for me to start looking up everything related to monads, F#, Haskell and FP in general. I was even astonished a bit I was ignoring this field for all the years I graduated from the university. That's what takes some of my free time during last 2 weeks ;)
My current conclusions are:
1. FP is what you must start studying right now - I think clearly understanding monads is what I'd call minimum here. Speaking shortly, FP times have came. Its upcoming application areas:
Asynchronous programming. Likely, you know, that pure FP programs are intrinsically concurrent, because there are no side effects. Take a look as async monad in F# as well. If you aren't sure if async programming is really important, think what's increasing during last 5 years: the count of CPU cores, or CPU frequency. Free lunch is over. Monads. They're native for FP languages, and provide really powerful abstraction for dealing with side effects safely. I was quite surprised to know that e.g. IEnumerable<T> is just a particular implementation of monad. Since I'm not feeling myself fully comfortable in this area, I'll just give you some links related to further. But I can promise you it will be at least really interesting to study this. Integrated DSLs. Functional style favors building DSLs integrated into a "host language" (i.e. fully based on its syntax). You may look at LINQ as DSL built for dealing with sequences in C#; Rx Framework is the same DSL built for events. You shouldn't build neither a king of execution platform for such a language, nor compiler, its libraries and so on, but you may use all the stuff offered by the host platform there. Obviously, that's great. That's the "truth in the middle" about DSLs I was talking about :)
2. Haskell is highly recommended language to start from - every FP guru talks mainly on this language, so you'll need it to understand even C9 videos related to FP and monads ;)
3. F# also worth studying - at least because it is primary functional language on .NET. It is quite close to pure FP languages by offered features (but it can interact with imperative ones via .NET platform), but nearly as fast as C#. Likely, you won't need it on practice - C# is "functional enough", and as all of us seen, it constantly moves to functional direction (btw, that's one more reason to study FP fundamentals). Likely, C# will anyway be the mainstream language on .NET. But this does not depreciate F# - it's simply useful to know and understand it.
4. It's simply wrong to set OOP oppositely to FP, so don't worry much about usability of your existing knowledge. Contemporary FP languages supports all you know in OOP (F# and Haskell are not exceptions here). But they push you to use a bit different way of thinking about programs you write. FP is opposite to imperative programming (which really becomes less and less interesting), and OOP is a kind of extension to both of these techniques allowing you to describe real world entities more conveniently. That's the second "truth in the middle" I was talking about.
The most interesting part - the links:
Free lunch is over. That's for those ones who isn't fully convinced programming techniques we use now are going to change. Not in future - they're changing right now.
So you're curious, what is a monad? Here is a very short answer @ stackoverflow explaining this. At least this will give you a kind of short introduction. To fully understand why they have appeared in FP and bind the description with practice, take a look at the description of IO in Haskell.
Let's bind this to your existing C# knowledge now. The Marvels of Monads and Functional .NET - LINQ or Language Integrated Monads? - good articles to start from. You'll learn that IEnumerable<T> is just a particular example of monad, but LINQ syntax in C# allows you to deal with generally any others of them.
Implementing Async Computations in C# - an overview of async monad for C# developers Monadic Parser Combinators using C# 3.0 - that's another example showing when they're attractive.
I suspect now you are either even more interested, curious and eager to learn, or have already decided to leave this for some future studying (btw, that's pretty reasonable as well). So if you're facing #1 case, here are great C9 videos explaining this:
Brian Beckman: Monads, Monoids and Mort Brian Beckman: Don't fear the Monads (saying "don't fear" frequently means "that's exactly what you must fear!", LOL ;) ) Wes Dyer - Marvel of Monads
Finally, you should take a look at the following categories at Channel 9:
Videos tagged by "Monads" Videos tagged by "Reactive Framework" Videos tagged by "C9 Lectures" @ Channel 9 - there are Erik Meijer's lectures on functional programming. Just for out of 13 for now, but take a look who's author.
Have a nice trip ;)
P.S. If you work @ Xtensive, the videos can be found at "\\Storage\Media\Video\IT\Functional Programming". [Less]
|
|
Posted
over 3 years
ago
by
Dmitri Maximov
|
|
Posted
over 3 years
ago
by
Dmitri Maximov
|
|
Posted
over 3 years
ago
by
nore...@blogger.com (Alex Yakunin)
That's true I discovered few days ago after post in our forum. The story behind is quite simple: I still use Windows Server 2003 (it's still alive ;) ) at my workplace and Windows Vista at home. Since I'm the person responsible for installer, I
... [More]
launch it and test mainly by my own, although I frequently ask the guys from my team to test it as well on their own PCs. So how this could happen that:
Nothing is properly installed on any 64 bit Windows. Basically, everything is copied, but nothing more! The process of ASP.NET sample installation was actually changing nothing at all on IIS 7!
64 bit Windows support was broken mainly because of wrong detection of Visual Studio paths there and few an issue related to bracket handling in .bat files - I'll write about this later, but briefly, even echo "Something (x86)" may lead to an error there. Much worse case is if "%somePathWithBrackets%"=="" ... :)
ASP.NET sample installation was broken by much simpler reason: I used the same VBScript as for IIS 6 there instead of appcmd.exe. Shame for me :( Btw, I suspect I know why I didn't knew this: I have installed DO4 on home PC. Since installer is actually incapable of not just installing the sample, but uninstalling it as well, I was simply opening my own pre-configured version of it. "Voila - it works!"
The only thing surprising me is why no one wrote about all this stuff. We track all the downloads (likely, you know this - we send few notifications after each one). So I know how many persons have downloaded DO4 e.g. in last week, and I got just one complain...
Btw, we know documentation and installation are the worst problems people face - by our "exit polls". I admit I did may be 90% of what I could to improve the installation, integration with MSBuild and very basic usability during last month, so I hope these bugs are the last important ones there - today I'm planning to fix the last minor problem with ASP.NET sample that currently exposes itself on 64 bit Windows Server 2008 (probably, the issue is related to any IIS 7). The nightly build that is published right now installs everything properly, the only exception is this issue.
And finally, a single conclusion: I should always keep in mind which failures are the most expensive!
Earlier I wrote our testing process is very comprehensive: we're constantly keeping just few failing tests (mainly, for issues we're resolving right now) and pretty good code coverage. Take a look at TeamCity screenshots I made few minutes ago.
Imagine:
36 build configurations running tests on all versions of all databases we support ~ 1100 tests for Xtensive.Storage ~ 1000 tests for its dependencies Pre-commit tests, 5 build agents and so on... But these test do not covers installer!
Yes, testing of installers is what really hard to automatize. But does good product testing matters at all, if its installer fails in may be 80% of cases because of just few bugs? I'm thinking, how costly may such a buggy installer be... "I have 64 bit Windows. Install was ok, but nothing works. So I uninstalled it and added the product and the company behind into in my personal blacklist." Likely, that's what really happened with 70% of our downloads in just first 5 minutes of their completion. Taking into account there is poor documentation as well, I can easily raise up the number to 95%. So that's the answer to my own question: "Why no one reports there are bugs in installer?".
I apologize for this huge mistake I made. I hope if you're reading this blog, you're the one of persons that did not blacklisted us because of this :( We'll publish completely polished installer in a day or so. [Less]
|
|
Posted
over 3 years
ago
by
nore...@blogger.com (Alex Yakunin)
I was always curious how Dmitri Maximov creates his nice diagrams, but as it frequently happens, I asked this just today. His answer has astonished me: he uses yUML, online UML diagram generator. So actually his diagrams are defined inside <img src="..." /> tags!
That's really nice!
|
|
Posted
over 3 years
ago
by
Dmitri Maximov
|
|
Posted
over 3 years
ago
by
nore...@blogger.com (Alex Yakunin)
Today's nightly build of DO4 gets 100% score on LINQ tests at ORMBattle.NET! So currently LINQ scoreboard looks like: 100,0%: DataObjects.Net 88,9%: LINQ to SQL 75,2%: ADO.NET Entity Framework 35,9%: BLToolkit 29,9%:
... [More]
NHibernate
I listed the results for freeware and Microsoft products only. We plan to update ORMBattle.NET scoreboard this or next week. [Less]
|