Now that ASP.NET MVC is headed into its third release version there is enough information out and about as to whether it is a viable platform for developing production implementations as compared to its more mature sibling, Web Forms.

For any developer who decides to do such comparative research, he or she will find a plethora of articles and documents touting the efficiencies of ASP.NET MVC over its older, more embedded forbear.  And all of these writings will be very much on target from a technical perspective.

ASP.NET MVC does in fact use the reliable MVC design pattern to more efficiently separate the web-based interface from the support modules allowing for more efficient testing of such constructs.  ASP.NET MVC does take advantage of the stateless nature of the Internet in a more direct way by not hiding its limitations from the developer.  ASP.NET MVC does use more efficient URL mapping instead of the bulkier page-life-cycle methodology that Web Forms uses tying the corresponding interface to a single middle-tier module (code-behind).

And ASP.NET MVC, though nearing its version 3.0 release, is still relatively new for the .NET community making it more tantalizing than using a more mature technology.

All of this is good from a technical perspective as it was good for Java at the time it was being touted as the new development paradigm for the Internet.  But ASP.NET MVC shares the same weakness that has always plagued the Java Community;  it is promoted by purists and evangelists for the sake of the technology and not its actual relationship to providing efficient methodologies for getting jobs done quickly, efficiently and with levels of corresponding quality.

Younger technicians with a penchant for using the latest technologies available or the slightly older ones who have been severely inundated with the latest techno-babble from vendors and vendor-evangelists see nothing wrong in merely using the technical advantages of newer technologies when compared to similar disadvantages to older ones.  However, does this in of itself make it the correct basis for decision making processes for real-world application implementation?  In a word; No…

Making such decisions in the chaotic, business world that we inhabit today takes experience in seeing the varying forms of failures that projects can experience from bad decision making.  And with a continuous software project failure rate still hovering around 70% since the inception of modern, application development in the 1960s, one has to be cognizant of what causes such failure in order to provide a better than average chance of having their project implementations succeed.  Unfortunately, most developers and technical managers are blind to such foresight since few take the time to study the actual requirements of software development and if they do, they rarely stand by proven methods of success.

Most often people simply give in to the stresses of just getting the job done as a result of supervisory pressures and tight deadlines.

Moving from a rather complex Web Forms project on my last consulting assignment which wrapped up this past August to my current position, I was recently exposed to the stark realities of rushing to use newer technologies based on their technical advantages over more mature options.

Moving into a new ASP.NET MVC project was admittedly very much like being thrown into a lake of icy cold water.  All of the familiar underpinnings of existing Web Form paradigms were gone replaced by an intimidating but somewhat familiar environment of “Classic ASP” but on steroids.  Despite the fears of many Web Form developers, that ASP.NET MVC is a step backwards towards the older methodologies of implementing web applications, such reactions are based upon only a knowledge of what this framework appears to be on the surface.

There is a lot more to it than just a reflection of “Classic ASP”, though it is very easy to understand why so many would have such a reaction.  I have done a number of years of “Classic ASP” as well as the equivalent number of years doing Web Forms and my initial reactions were exactly that of a giant step backwards.  However, once you get involved in understanding the intricacies of this new framework, you quickly find that the only thing “Classic” about ASP.NET MVC are the server tags mixed in with the HTML markup…

That being said, there are however, some severe penalties for using this platform without first thoroughly familiarizing oneself with it.

ASP.NET MVC is not a platform that is ready for “prime time” if your project has strict deadlines.  It is not ready for “prime time” if the project team is not familiar with the tools required to replace those that had become so familiar when developing with Web Forms.  And it is most definitely not ready for “prime time” if the project manager has no time for that level of “project risk” that will have to include a major learning curve for the team.

Simply put, ASP.NET MVC is not a “Rapid Application Development Environment” or “RADE” if one wants to conjure up similarities with the well-known insect terminator product…  It is simply designed to be too low-level for want of a better description in order for it to be able to provide quick responses  in terms of development efforts.  ASP.NET MVC is also an environment that enforces software engineering paradigms simply by its very nature.  And software engineering paradigms are both misunderstood and distrusted by most technical managers since all they see are the additional time requirements that such paradigms incur when scheduling a development project.  This in turn has encouraged such fads as XP and Agile programming both of which are no more than what we used to call “guerilla programming” in the mainframe world; fads that encourage minimalistic planning while turning out small bits of working code with little in-depth knowledge as to where the overall project should be heading.  Even planning in many instances is now considered a waste of time by many project managers; just “code & go” is what is actually wanted in many situations.

Because of its adherence to software engineering paradigms, ASP.NET MVC can literally sink a project if the user or client overseeing the project is in a constant state of chaos due to their own inability to articulate exactly what it is they want from the software development effort they have commissioned.  This is because ASP.NET MVC forces development to occur in a certain manner which also encourages a lot more fore-thought on the part of the development team.

However, one thing that can be said about this new environment is that once you get a working knowledge of it, it is not only quite a bit fun but terribly addictive because of the fact that it does provide such a nice way to implement a project’s middle-tier.  Once mastered, you are forced to reconsider development with a Web Form model merely due to the elegance and simplicity of the ASP.NET MVC paradigm.

Unfortunately however, such views are the sole purview of technical professionals and do not align with those of our clients.  And just as unfortunately, inept clients and users are pretty much the norm in our profession not the exception.  Thus the first hurdle that any new project engaging with the ASP.NET MVC environment should resolve is a good working control over how and when the user can make requirements changes.  True, they may be the ones footing the bill but it would behoove the project manager on such a project to make the user(s) understand that making chaotic demands on their development efforts will only guarantee that the bill will be much higher than desired.

Just as importantly and before and project team jumps into the use of ASP.NET MVC, the project user must be made to understand the benefits of each of the environments.  Thus if their overriding concern is quick development due to strict deadlines, than the choice should be made for the implementation of the Web Forms paradigm with the understanding that this paradigm will also not have the performance benefits that ASP.NET MVC naturally has with its bypassing of the heavier Web Form page-life cycle.  That being said, it should be noted that there are many things that can be done to improve the performance of Web Forms including the use of the highly efficient AJAX library, Gaia AJAX (http://gaiaware.net/).

If however, the client or user wants extensibility with an embedded level of maximum HTTP performance than the choice should than easily be for ASP.NET MVC.

But even here there are certain things that require understanding to properly implement an ASP.NET MVC project.  First and foremost, forget all of the hype that has been currently surrounding this new ASP.NET framework.  It will not do you any good if you run into trouble.  The hype comes from mostly technology evangelists who can’t see past their noses when it comes to adhering to good software engineering paradigms especially the paradigm about using the right tools based on the knowledge of the resources involved and the criteria of the project.  Yes, ASP.NET MVC technologically is superior to the Web Forms model but this is not a real-world consideration unless the client is adept enough to understand the ramifications that come with it.

And looking at ASP.NET MVC as a possible or eventual replacement for Web Forms would be a serious mistake when considering it as opposed to the older technology for a client’s requirements.  With its rapid development qualities along with a very large third-party support community, Web Forms is not going to disappear any time soon and nor does Microsoft have any plans to eliminate it from its development software stack.

ASP.NET MVC adheres to the MVC design pattern.  It does this rather altruistically since it has its origins with the ASP.NET MonoRail project (http://www.castleproject.org/).  The MVC design pattern is not an easy one to wrap your head around quickly if you have never used it.  And you will find that even the leading writers of ASP.NET texts on the subject also found similar difficulties in moving from the Web Form paradigm to that of MVC.

In a nutshell, and a very tiny one at that, ASP.NET MVC is made up of three critical components; the “View”, which is your web-page interface (actually any interface that is sent to the client), the “Controller” (and you can have more than one for any single web page) that processes the HTTP requests to the server and back to the client, and the “Model”, which in effect is the data structure that the controller will use to provide the “View” with its content.

In reality, this design pattern should actually be called VCM (View-Controller-Model) for the simple fact this is how most developers will see the relationships between these components.  Calling it MVC is actually a source of a tremendous amount of confusion which isn’t helped by the technical manuals that promote the theoretical methodologies for understanding this paradigm.  However, the reason for this moniker is that the theory behind this paradigm is that the “Model” is the most important aspect of it since it is the data definition behind any “View”.

I find that, when attempting to learn a new technology, a lot of theory just gets in the way and adds confusion to the subject matter.  And this is mostly because as professional developers we do not use theory to implement projects but in fact, use patterns of development processes that we know will work properly and get the job done.  This is also why design patterns are not very popular and tend to be used again by technology evangelists and those favoring theory.  There is nothing wrong with design patterns except for the fact that developers for the most part do not think in those terms.  And as long as most development projects are run in typical slipshod style, they never will.

When we compare ASP.NET MVC to the older Web Forms model in terms of project’s technical implementation, what becomes quickly apparent is that ASP.NET MVC has little third-party support when compared to the more mature Web Forms model.  If you look for tools to provide additional support for an ASP.NET MVC effort, what you find most commonly are the top tier JavaScript libraries such as jQuery (made part of a new project implementation by Visual Studio), MooTools, ExtJs, and PrototypeJS; none of which provide any “out of the box” capabilities similar to server controls.  However, both jQuery and ExtJS have quite a number of component plugins that can be used to extend the capabilities of both libraries.

All four libraries provide superior ways of handling client-side JavaScript implementations but there are learning curves involved for each as well as a requirement to develop extensive JavaScript code in order to provide similar functionality on the client as server controls do in the middle-tier.  This additional code development also drives up the time required to debug and test implementations forcing developers to literally use two different environments to debug their implementations; client-side debugging tools such as Firefox’s, “Firebug” and IE’s “Developer Toolbar” for the fornt-end and Visual Studio for the middle-tier.  So in this particular instance and others similar to it, making use of such libraries ease the implementation of client-side functionality but adds additional time required to do so.  Even if one is knowledgeable of a specific library it still requires the coding to make things work.

The question then is why bother when you have a lot of this already done for you in the form of server controls?  The answer given… it provides better performance without the extra baggage that server controls bring along with them since such implementations are all based upon AJAX.

However, this is only partly true.

What you are trading with in ASP.NET MVC is less server-control view-state baggage for a similar amount of JavaScript for the more complex web pages.  True, JavaScript does not expand the way view-state may with a data-grid or a grid-view but a heap of JavaScript has as many penalties for too much of it as does markup.  And if you need to present your data in a complex display such as a data-grid, the JavaScript to do it will all be sitting at the client.  The code that has to process these implementations has go somewhere…

In the end, like everything else in software development, there is little advantage to one or the other, its merely the advantages and\or disadvantages that you decide to accommodate.  And if you are crunched for time, using such a minimalistic framework as ASP.NET MVC for a highly complex project will not mitigate the stresses of pending deadlines when having to work much harder to get the same work done that the Web Forms model already provides for with many existing and mature tools.

A few major software houses such as Telerik Corporation are beginning to offer competent controls for the ASP.NET MVC framework.  However, after the length of time the MVC implementation has been available, the amount of support is not gaining a similar broad base of momentum as was done with the server control vendor community.  In addition, such controls are similarly JavaScript based as the previously mentioned libraries so there is really nothing new here.

ASP.NET MVC evangelists are touting the idea that such support will be forthcoming but don’t hold your breath.  As long as Web Forms is the easier of the two methodologies to use to implement web-based applications quickly, this is where third-party control vendors are going to continue to emphasize their product development efforts.  And there is little money to be made with JavaScript libraries as all the current popular ones are free.

But let’s forget for a moment the technology support for such development and take a look at the learning curve involved to implement a complex ASP.NET MVC application.  Where Web Forms attempted to hide the underbelly of the Internet from most development efforts (and did a reasonable job of doing this as well), ASP.NET MVC comes with the requirement that you actually have to understand how the Internet works with knowledge requirements that involve routing mechanisms, POST and GET processes, Request and Response processes and the like while intermixing all of this with a lot of JavaScript and AJAX processes as well.  What was originally done at the server level as well as the client is now turned on its head with the admonition that more can now be done at the client providing a better “user experience”.

However, much of this promotion of ASP.NET MVC is based upon the idea that it is also “now” the “correct and elegant” way to do web-development  due to its compactness as well as the correct technique for working with the stateless environment of the HTTP protocol and topology of the web.  For once I have to agree with such popularizations; ASP.NET MVC does in fact work at a more natural level with the Internet’s topology. Nonetheless, this criteria for ASP.NET MVC is not a real-world response to the nature of most software development efforts but instead a purist view for the use of a technology for the sake of technology; a deadly mistake for its adoption when schedules are tight.

The idea of Rapid Application Development is NOT to go low-level as ASP.NET MVC encourages but to keep it at a substantially higher level in order to get the job done quickly and efficiently.  And this is where ASP.NET MVC simply cannot currently compete with the Web Forms paradigm in this instance.

The idea that as the Internet has evolved  along with newer types of business requirements along with it is complete and utter nonsense.  The Internet has neither evolved since its inception in the 1960s and 1970s and nor have business requirements changed.  The internet still retains the same topology and protocols it was given with its inception and business managers are still making the same unplanned requests they have always made towards IT personnel with the only difference being that they have been subjugated to much more propaganda by the technology vendors who are all promising “magic bullets” to their business issues.

Nonetheless, ASP.NET MVC is above all an excellent choice when and if a development team has the time to do the job properly and everyone is well versed in the areas of expertise that are needed to support the project due to the learning curves required to become competent with this framework.   It is not a good choice when basing such a decision on the promotions of technical purists, engineering types, and technology evangelists.  Such promotions are often short cited,  self-serving, or the result of narrowly focused training.

Last but not least is the perverted admonition for this new paradigm that by using it will provide an elimination of  “the spaghetti code that Web Forms often encouraged”.  In fact, for those of us who did “Classic ASP” for quite a number of years, this is the same exact reasoning that was given for moving to the new ASP.NET Web Forms model when it was first commercially released in 2001.  In fact, Microsoft is great at regurgitating the same reasons for using a new technology that were used to get rid of an older one.  Stay in the field long enough and it gets sadly very repetitive.

There is no such thing as a paradigm being used to prevent sloppy coding habits.  Any language and any paradigm can be turned into a complete mess.  You just need the right incompetents to do it or the lack of time that prevents quality personnel from developing quality code.

Does all this mean that ASP.NET MVC has a questionable future for real world applications? Absolutely not!  On the contrary, ASP.NET MVC has a very bright future due its natural bent towards the Internet architecture

It simply means that it is not a good choice currently for getting a job done efficiently and quickly when a client or a corporate user is controlling a project’s scheduling and they are keeping to very tight deadlines.  However, the more important aspect of this discussion has nothing to do with which model works better or doesn’t.  Instead it has to do with the realities of Internet development.  And those realities include the fact that the majority of tools used to develop web applications with are nothing more than “kludges” or “parlor tricks” based on a current set of circumstances and this is especially true for the popular AJAX paradigm.  By now with the amount of effort and time that vendors have expended in developing tools alongside the efforts that developers have expended in implementing such applications one would think that a standardized framework would have been refined well enough by now to offer pretty much what any web application requires in terms of acceptable performance and user-interface capabilities.  Instead the industry has bounced from scripted languages to compiled languages and back again all the while throwing the Internet development processes along the way into the same turmoil.

Such turmoil serves only one purpose and that is to support the capabilities of vendors to maintain their brand and make revenues on them.  Whether you elect to  use an MVC paradigm with the .NET framework or not will not make a stark difference in application performance with well-designed and well implemented development efforts in which either are properly tuned for performance benefits.  Such efforts will most often provide similar levels of performance since Internet performance is still mostly a factor of the hardware and bandwidth supporting a specific application as well as the amount of data being sent to and from web-pages.

Black Falcon

The following links, tools and books will provide enough in-depth knowledge to help you decide if your next production project has the criteria that could support an ASP.NET MVC implementation…

Dino Esposito on ASP.NET MVC…

Dino Esposito provides the most balanced coverage on the ASP.NET MVC framework that I have seen to date…

http://msdn.microsoft.com/en-us/magazine/dd942833.aspx#id0080027

If you are working on an assignment as a single consultant, independent, or even an employee singularly responsible for his or her project, moving your project’s code base to the server environments whether it be development, user-acceptance, or production is always a stressful situation since no two server environments are ever the same and no server environment mirrors that of a local developer’s workstation environment.

In practically all cases in the environments I have worked in, the issues that have arisen from project moves are either security permissions or configuration. It is very rare to find a project that is working properly on a local workstation to suddenly cease working in a server environment due to something being wrong within the code base.

However, one area that can drive any technician to the brink of complete despair, especially when moving ASP.NET projects between environments, is newly defined application parameters that have been added into the “web.config” file. Most often the server web.config files are not touched by developers since they often include additional parameters unique to the server environment in which they reside. As a result, application specific parameters have to be promoted either by sending the appropriate server group the information or doing it on one’s own.

The biggest issue then is remembering to do this.

Under certain circumstances the lack of any such parameter can yield very ambiguous application errors that can take long periods of time to uncover given that many of us would have forgotten about a parameter update to a server’s web.config file simply due to stress and tensions. It happens because we are Human… Though, often enough that does not seem to be reasonable enough excuse for such a lapse.

There is a very simple way to always avoid such a situation with a little snippet of code that follows.

Most often when retrieving a parameter from the web.config file we simply use the following code:

To guarantee that a web.config parameter exists or have the application tell you that it doesn’t is by adding the following code to all such parameter retrievals within forms, code-behind modules and business objects while using a centralized error-handler component.

Trust me… This simple additional coding practice can save one a lot of embarrassment and stress in tight situations.

This code can be easily converted to VB.NET by making use of the excellent online conversion utility found at http://www.developerfusion.com/tools/

Black Falcon

Every developer knows that both the Microsoft Datagrid and the newer Gridview controls are quite versatile when it comes to displaying data. They both offer a raft of capabilities that makes it far easier to provide tabular data displays than was easily possible with “Classic ASP”. One of these capabilities is the capability to page through data. However, the paging process is rather inefficient as the potential data for display grows in size.

In such paging, as experienced developers know, all of the data is returned to the control and the selected “slice” of data is then used for the selected page. As the number of records grows into the thousands for such displays, performance starts to suffer considerably.

The answer to this issue is to create backend stored-procedure that will do the “data slicing” at the database end and thus only return that data, which is to be currently displayed.

With the new capabilities in SQL Server 2005 and 2008 such as the ROW_NUMBER() function, slicing data on the backend has become much easier. However, if you are working at a client that has let the new technologies pass them by and you find yourself working with SQL Server 2000 you will need a stored procedure that mimics the new capabilities of the new database engines.

The following stored procedure code provides one way to handle paging with SQL Server 2000. The code is in use at a client I have been working at and is far more extensive than what is shown here. However, what is shown below is what is needed to get basic paging at the backend of a SQL Server 2000 database working…

Black Falcon

When developing ASP.NET applications, one of the most important aspects of that development is the management of application or session-state for an application or a user. A variety of techniques have been implemented, all of them good. My personal favorite is to use the built-in ASP.NET database for such purposes since it allows me to offload some of the memory management to SQL Server thereby splitting the processes between IIS and another machine… or at least a process.

However, actually implementing state within code has often been quite a messy proposition with many developers simply using application or session variables within code wherever and whenever they are needed. The result of this is that state variables are then peppered throughout the code base with little or no sense of organization.

To alleviate this issue many companies have developed their own state management processes in order to bring a more organized approach to the situation. However, one does not need to get overly complex in order to do this for most applications.

The code that follows comprises two classes that can be easily implemented as an assembly, which can be referenced by the application it applies to enforcing not only a modularized layer for application and session state management but an organizational model that will make it much easier for new members of a project to understand what variables involve state in a central location.

The first class, which is the “work horse” class I have called, “clsWebCache”. Of course you can call it whatever suits your naming convention paradigm. I always prefix my class names with the moniker of “cls” so that developers will automatically know what such a module is.

“clsWebCache” has three primary methods; one to persist state, one to retrieve it, and one to delete it. As such, this class will allow you to save state to either the application cache or session cache with the use of a single character indicator. The use of the “object” data type for the actual value allows you to save any type of data that is required. However, with complex data types you will most often have to do casting when retrieving data.

Notice also that all of the methods are provided the access modifier of “internal” (VB.NET would be “Friend”). This is done so that the class is global only to the class library it a part of.

The class that developers would interface with is where the actual items to be persisted are defined. This class I have called, “clsWebCacheObjects”. And it is in this class where you may define any type of item or collection you would like to persist. In the code below I several types of data being stored…

These two classes do not yield anything earth shattering in terms of technology but they do provide a good way to organize an application’s state as well as enforce some discipline as to what gets put into it…

Black Falcon

“ORAHelper” is the latest release from Black Falcon Software in its “Data Access Layer” project at Microsoft’s CodePlex.

With the many new database provider “factories” appearing on the market both in commercial and free open-source form, one would wonder why add to the fray with a new DAL for Oracle. The reason is simple, “KISS” or “Keep it simple, stupid!”.

Most application development today, no matter what the platform, requires only a single database engine. Though there are projects that require access to multiple databases, these projects are usually relegated to the complex and are in the domain of sophisticated IT organizations. Some, to be fair, are not and can be found in smaller arenas but the number remains rather small when compared to single database applications.

The use of such “heavy duty” tools are perfect solutions when programming such projects but those who only need to program for one database, and in this case Oracle, require only a single interface for their needs.

Enter, “ORAHelper”, which has all of the standard features that any DAL would have to provide for full application development. If you have already tried our “SQL Server” DAL, than you will find it quite easy to use “ORAHelper” since it contains practically the same functionality.

All project and source code modules are provided in both their C# and VB.NET versions for both the 2.0 and 3.5 .NET Frameworks along with complete documentation for the API. In addition, for ease of testing a complete test-client module has been.

To get this software, simply go to the link below to perform the download.

If you like the software please leave your comments here or write to Black Falcon Software at the following address… support@blackfalconsoftware.com

Black Falcon

Download SQLHelper from our CodePlex site…

Suggested Reading…

Professional Microsoft SQL Server 2008 Programming (Wrox Programmer to Programmer)

One of the most critical aspects of writing a document for a new client regarding the installation of the DotNETNuke (DNN) platform is to tell the client what features he or she could expect to get from such an installation.

Here you are preparing such a proposal and you want a simple, well outlined feature-list for your potential client so you head on over to http://www.dotenetuke.com to get such a list and after a few moments you find yourself stopped dead in your tracks. You can’t seem to find such a list beyond the general capabilities provided in the DNN feature overview.

Don’t despair… The DNN site is becoming like Microsoft’s due to its popularity and the inability of the DNN team to keep up with their own success and increasing amount of documentation. And if you have ever tried to find anything on Microsoft’s site you will understand.

The information you are seeking in this respect is actually in the DNN “Help” area. Why a technical, pre-sales piece of documentation would be filed under a “Help” area is a question for the DNN team. However, if you do not want to gather all of this information yourself, simply download the Zip-file below to get both a Word document as well as its corresponding PDF version of a nicely laid out feature list that is perfect as additional documentation for any client proposal involving the implementation of the DNN Framework.

And if you want to update the Word document but prefer to distribute it as a PDF, such as the one that accompanies the download, then simply go http://www.dopdf.com/ and download the excellent Word-To-PDF converter tool. It is not only an excellent tool but is also Freeware as well. Kudos to Softland for their excellent product…

Black Falcon

 

DotNETNuke (DNN), is probably one of the best complete CMS frameworks developed for the ASP.NET platform. Yes, there are others, but in my research none of these alternative frameworks combine the capabilities and extensibility that the current DNN platform does.

Unfortunately, the success of DNN has had a detrimental effect on their ongoing documentation efforts, which many can already attest are falling behind in their compatibility to current versions and framework extensions. Downloaded documentation files are still displaying 2006\2007 timestamps and have not been revisited since.

The DNN site itself has become as proportionately extensive as that of Microsoft’s. The result, as any technician who has visited the site can attest to, is a maddening labyrinth of articles, blogs, notes, and documentation files that seemingly have little connection or relevance to each other in terms of their placement within the site let alone the aging nature just mentioned.

Installation then from a source-code package, which most professional developers would select, if for nothing else curiosity, is basically well-done but has issues with minor aspects of the installation process that could affect such an installation along with the sanity of the developer doing it.

Several months ago, I wrote a technical memorandum to the DNN team clarifying these installation issues, while demonstrating that by adding just some minor re-organization to the installation information along with some minor clarifications, a source-code package installation could be made much easier and less fraught with issues that could literally cancel out any promising endeavor for the use of this framework.

For your benefit, this document has now been posted here for developers who are looking to install DNN on their company site’s servers or their own. The technical notes included should make any such installation a rather easy process without any of the potential headaches…

The document that follows was accepted by the people at DNN Corporation and I was placed on their list for additional assistance with their documentation projects.

Black Falcon

Re: Installing DNN 5.01.01 From The Source CodeHello…

I have just finished about 9 hours worth of in-depth analysis on the DotNETNuke Framework in terms of installation issues with both your source package as well as the standard installation package… and I have a number of comments to make.

As a senior software engineer with over 35 years in the field I have done just about everything there is to do in the business application arena so I have seen a wide swath of issues with scores of applications and frameworks.  So if you would allow, I speak here from extensive experience in the IT field/

First and foremost, DotNETNuke is an incredible framework given the breadth of its capabilities and the community that supports it. And for once something of this scale is written in VB.NET and not C#.

I have been researching the use of this framework for years and have finally been able to propose it to my client as a consideration for the document management functionality they would like to offer both the corporate environment as well as the many subsidiaries this client owns.  This proposal is going into some very serious business environments that have nothing to do with current web fads, startups and the like.  As  a result, if this proposal is accepted, The DotNETNuke community just may see an interesting uptick in their installations that involve some very serious business concerns.

That being said, there are a number of installation issues that have to be addressed; there are simply too many issues that come up without immediate answers available.  This contention is corroborated by the many installation problems reported in your forums.

Most often technical personnel will be doing DNN installations for their sites with a lesser number being installed by end-users with some technical knowledge (ie: web hosting DNN installations).  Thus the installation support should be first and foremost towards the technician and not the administrator who may or may not be competent technically.   And though you have made a good attempt at performing a non-technical installation, I have found  from my own attempts at running the installs (and I have done several) that there are too many questions that a technical person would naturally pose that aren’t clarified with any supporting information to help him or her make informed judgments as to why they are selecting a certain option or updating some installation code.

For example, your installation to SQL Server 2008 Express, though it works just fine, actually goes against the “grain”, more or less, as to how database development professional would view such an installation.  DNN makes use of the new “User Instance” in the express versions of SQL-Server but what database developer would use such an attribute?  I researched the use of this new addition to SQL Server and found it to be very similar in nature to typed-datasets, designed for less technical personnel but highly limiting to well trained personnel.  I certainly would never use it but try setting up DNN with SQL Server 2008 Express without the “User Instance=True” and you get a minefield of issues that are not readily explained or apparent.

I run SQL Server Express 2008 on my laptop and workstation at home.  My laptop supports my work at my client.  On my personal workstation it is simply there for quick work when I do not want to power up my database server for the full versions.  I connect to SQL Server 2008 Express the same way I connect to my server databases.  It should be that way with DNN or at least an option that DNN understands right out of the box making connection string updates easy and without any issues.

In terms of the DNN source-package installs, this can be a nightmare of potential pitfalls for the technician.  And yet it doesn’t have to be.  Like many .NET web-based applications that are designed for distribution to the public, the solution structure can often be a determining factor in the success or failure of such an installation.  Some solutions are built in such an arcane fashion that one small change to its setup can blow the entire installation out of the water.  To some extent this is true of DNN, maybe not so much as a result of the solution structure but from the lack of detail and information as to why it is structured in the way it is and the variety of dependencies that exist.  In addition, installing the source-package for a SQL Server 2008 Express environment has some different aspects to it than that of a server environment as noted above.  All of this should be clearly spelled out for a developer who is tackling such an installation.

For starters, your “README” file is in the wrong place.  It should be placed at the top-most level of your source package where the solution files reside.  It should also scream “READ ME BEFORE DOING ANYTHING WITH THIS SOURCE CODE!!!

Second, to make this file more prominent it should be as nicely setup as your PDF manuals are to further the impression on the new developer that this information is critical to a successful source-package installation.

In addition, I have made some notes, which I believe will resolve numerous installation issues which you may want to elaborate on and include in this file.  They are as follows…

• Rename the “Development.config” file in the “Website” directory to “web.config” (You say this in your own Notes but as a result of the placement of the file such information is not readily significant.)
• Place the updated\renamed “web.config” in both the top-most directory where the solution “.sln” files are andkeep it as well in the “Website” directory.  This is probably not required in terms of placing this file in bothdirectories but it certainly will avoid any issues while running an installation.
• Create a Virtual Directory in IIS called DotNetNuke which points to the “Website” directory where theDotNetNuke.webproj file exists.  It is preferable to place the DotNETNuke directories and files in a separatedirectory structure that is not part of “inetpub\wwwroot” so that no potential conflicts may arise during compileand installation.
• Compile the entire DotNETNuke solution and make sure that there are no errors.  If errors are listed this means that the web.config files have not been properly updated and placed.  Go back to items 1 and 2…
• If using SQL-Server 2000, 2005, or 2008, create ONLY the database structure on SQL-Server 2000, 2005, or 2008 before attempting to run a source-package installation; obtain the proper connection information and update the connection strings in bothweb.config files with the added connection-string parameter of “User Instance=False”
• If using SQL-Server 2005\2008 Express, DO NOT CHANGE EXISTING CONNECTION STRINGS except for database name; leave the login credentials alone. User Instance=True”  (this is required when using SQL-Server Express editions for DNN

If you prepare the “README” file and these notes are followed in the order they are listed you should see a substantial reduction in with reported installation issues.

Finally, I would recommend preparing a detailed source-package manual for the current version of DNN that not only details the notes I have mentioned but the many details that comprise the understanding of the source-package such as what each module does, why it is included, and what issues can come up if the appropriate references are not left intact.

Thank you for your consideration and time in reviewing this information.

You would think that one of the most popular dynamic languages in the industry would have a rather straight-forward process of being installed in a Windows environment with the capability of running under IIS. The disappointing news is that PHP is a literal brain-crushing, mind-blowing, nightmarish experience when it comes to this implementation scenario.

Why? More than likely because PHP was never really designed to run under Windows and is more at home in the Linux world. However, it is now in Windows environment and getting increasingly stronger in it on a daily basis.

One could ask, why a technical site devoted to .NET technologies is suddenly publishing an article on PHP and the answer is fairly straight-forward. If you develop web-sites, even if you are a hard-core .NET professional at some point you are going to run into PHP. And since I have found myself in this very position recently I want to get the information out before I completely forget it…

In the .NET world we already have Phalanger, which is a Microsoft sponsored project for PHP.NET and there is also “Iron-PHP” along with an add-on for Visual Studio if you prefer to remain in that environment.

A lot of Internet web-sites are developed using this tool and there is no sign of this trend abating since it is not only free to obtain but works with all the major components in the web world such as databases.

However, getting it up and running under IIS is still sort of a “Black Art” that I hope this article will make a little easier to handle.

So let’s begin…

First and foremost you have to make a decision if you want to run PHP with plain old CGI processing or the newer FastCGI option. Depending on how your system has been configured, such as those you may be using at your place of employment, you may not be able to install FastCGI and PHP along side with it.

If you install FastCGI and your PHP installer throws up an error during the install process that states that the PHP package may be corrupted, this is a sure sign that your FastCGI implementation on that machine is not compatible with the PHP installation. This has nothing to do with PHP but with the underlying configuration of your machine.

If you are comfortable that you can install FastCGI, go here to obtain the Microsoft version for IIS 5.1 and 6.0… http://www.iis.net/expand/fastcgi

Before you install FastCGI you may have to install the Microsoft Web Platform Installer first. Simply download it from the link noted above to a directory on your machine and execute the installer. Than you can go back to the web page above and begin the FastCGI installation process.

For Vista users you can find a similar article here… http://learn.iis.net/page.aspx/246/using-fastcgi-to-host-php-applications-on-iis-70/. And for both Vista and Windows-7 users, the following article applies… http://technet.microsoft.com/en-us/library/cc753077%28WS.10%29.aspx

Since FastCGI is already an installed component with Vista and Windows-7, these articles at the links above will describe how to make use of it.

For those of us who have yet to upgrade from XP, we have just as much work to do with the addition of installing the FastCGI component if we elect to use it.

Once installed, check to make sure that it was done successfully by checking for the fcgiconfig.js file in your “inetsrv” directory, which can be found in “Windows\System32\inetsrv”. If its there you can proceed. There should be no problems with installing the FastCGI component but checking to make sure is just a good practice.

Now we need PHP itself. Head on over to the following link and make sure you download the “non-thread-safe” version of PHP of the Windows installer… http://www.php.net/downloads.php. According to one document I came across the same holds true for Vista and Windows-7 users. You can review this document at http://www.hauser-wenz.de/s9y/index.php?/archives/280-Installing-PHP-on-Windows-7.html which is a guide written up for Windows-7 installations.

For Windows Vista, this article will apply… http://www.mattsilverman.com/2009/03/install-php-on-windows-vista.html

Ok… Now for the PHP installation….

One thing to take note of. PHP does not like directory names with spaces in them. So don’t use them! As a result, don’t install PHP into “Program Files\PHP”. You will most likely have issues either during the install or after it. The common recommendation is “C:\PHP” for your installation. It is a rather safe bet. However, you can install PHP to any directory of your choosing. Just make sure there are no spaces anywhere in the path.

Once installed, you will find your “PHP.ini file in the root installation directory (ie: “C:\PHP”). You now have to make a few minor updates to this file. Here they are…

Under CGI:

• fastcgi.impersonate = 0
• fastcgi.logging = 0
• cgi.fix_pathinfo=1
• cgi.force_redirect = 0

Under FastCGI

• fastcgi.impersonate = 1
• fastcgi.logging = 0
• cgi.fix_pathinfo=1
• cgi.force_redirect = 0

If you are using FastCGI than you will also have to run the following script to get it initialized properly for IIS…

cscript %windir%\system32\inetsrv\fcgiconfig.js -add -section:"PHP" ^ -extension:php -path:"C:\PHP\php-cgi.exe"

(see the article at the end of this piece… “PHP – Miccrosoft IIS 5.1 and IIS 6.0”)

Before running the script make sure you change the path name to where your php-cgi.exe module is located.

Next, you should add PHP default document to IIS as “index.php” via your PHP virtual site’s “Properties” option…

And finally, you will have to add the “.php” extension mapping to your PHP virtual directory. And this is a critical implementation. Without it, your PHP scripts simply will not run.

Of course, when you try to do this in XP you will find that you will be unable to save your new mapped extension. You will immediately think this is a permissions issue. It isn’t but merely one of those undocumented features by Microsoft to drive technicians insane. See the following article for the complete work-around for this annoyance.

If you are going to use FastCGI and you have run the initialization script successfully along with the rest of the steps outlined, you should now be able to run a PHP script file under IIS. If you are using just CGI than the initialization script is not part of the process.

Now save the following script to your PHP projects directory…


<?php

echo “test”;

?>

Open up your browser and access this script via a URL (http://…). You should see “Test” appear in the browser’s display. If you do… you’re set to go…

Now that you have gotten PHP installed, what do you do with it? Creating PHP scripts in a text editor is fine if you are a hard-core UNIX\Linux aficionado. However, for the rest of us who have to get work done, an IDE is a far superior choice. The problem is that most PHP IDEs are rather useless or overly expensive since this is still rather a niche market.

However, the one IDE that stands above all others and will give you a completely professional environment is “Netbeans”. “Netbeans” will provide you with everything you need to develop robust PHP web applications, including a debugger. And the best part is that it is completely free.

Since “Netbeans” was originally developed for Java and has since added a number of dynamic languages to its platform, you could download the entire package if you are interested. However, you don’t have to. All you need is “Netbeans-PHP”, which is a subset of the entire platform.

You can download a copy of Netbeans at http://netbeans.org/downloads/index.html

The image below shows you the download option you should select at the Netbeans site…

Black Falcon

27 December 2009 by Yair Amichai-Hamburger

Go to Article Source…

“THE age of melancholy” is how psychologist Daniel Goleman describes our era. People today experience more depression than previous generations, despite the technological wonders that help us every day. It might be because of them.

Our lifestyles are increasingly driven by technology. Phones, computers and the internet pervade our days. There is a constant, nagging need to check for texts and email, to update Facebook, MySpace and LinkedIn profiles, to acquire the latest notebook or 3G cellphone.

Are we being served by these technological wonders or have we become enslaved by them? I study the psychology of technology, and it seems to me that we are sleepwalking into a world where technology is severely affecting our well-being. Technology can be hugely useful in the fast lane of modern living, but we need to stop it from taking over.

For many of us it is becoming increasingly difficult to control the impulse to check our inbox yet again or see whether the headlines have changed since we last looked. Our children are in a similar position, scared to miss a vital Tweet or status update on Facebook. In many homes, the computer has become the centre of attention; it is the medium through which we work and play.

How did this arise, and what is it doing to us? In this era of mass consumption, we are surrounded by advertising that urges us to find fulfilment through the acquisition of material goods. As a result, adults and children increasingly believe that in order to belong and feel good about themselves, they must own the latest model or gadget.

Yet research by psychologist Tim Kasser of Knox College in Galesburg, Illinois, has shown that people who place a high value on material goals are unhappier than those who are less materialistic. Materialism is also associated with lower self-esteem, greater narcissism, greater tendency to compare oneself unfavourably with other people, less empathy and more conflict in relationships.

Our culture also constantly reminds us that time is money. This implies a need for total efficiency, which is why we are allowing laptop computers and mobile phones to blur the separation between work and home. As one unhappy human-resource manager in a high-tech company put it: “They gave me a mobile phone so they can own me 24 hours a day, and a portable computer, so my office is now with me all the time – I cannot break out of this pressure.” Sound familiar?

Psychologists generally believe that the lack of a clear separation between work and home significantly damages our relationships with loved ones. It also predisposes us to focus on the here and now at the expense of long-term goals.

By imposing these twin pressures, modern society is in danger of swapping standard of living for quality of life. We need ways to help recover those increasingly large parts of our lives that we have ceded to technology, to regain mastery over technology and learn to use it in a healthy and positive way.

My prescription is self-determination theory, developed by psychologists Edward Deci and Richard Ryan of the University of Rochester in New York state. It identifies three vital elements of healthy personal development and functioning which I think can be used to recalibrate our relationship with technology.

The first is autonomy – the feeling that our activities are self-chosen and self-endorsed. When we feel in control, we are able to organise our priorities and place effective boundaries around them. But when we feel we have insufficient control, it leaves us vulnerable to our impulses and causes us to abdicate decisions to other people. It is easy to see how technology undermines autonomy, but also how to regain it. This may be as simple as switching off mobile phones during meals and family time, setting aside specific times to answer emails, and being available only when we choose to be.

We also need a sense of competence, a belief that our actions are effective. In this respect our relationship with technology is complex, because many of us feel competent when we deal with an email, when we have the newest BlackBerry, or because 50 people enjoyed the holiday snaps we posted on Facebook. But being truly competent must be a continuation of our autonomy: knowing which activities are important to us and carrying them out in the most effectual way possible, making use of technology where applicable.

The other factor is relatedness: our need to feel close to other people. Technology is a threat to this. Devices like the iPod can be used to create a bubble that disconnects us from normal human interactions, and while some virtual relationships may be truly meaningful, in many cases they come at the expense of real-world connections. Psychologists have found that the pivotal difference between happy and unhappy people is the presence or absence of rich and satisfying social relationships. Spending meaningful time with friends, family and partners is necessary for happiness.

I would add a fourth factor, too: critical thinking. In today’s world, where we are potentially available 24/7 to absorb messages from well-honed advertisements, it is vital that we know how to analyse and evaluate their validity – and to neutralise them where necessary.

I believe that autonomy, competence, relatedness and critical thinking are the best ways to establish a balanced approach to technology, and so enhance our well-being.

Yair Amichai-Hamburger is director of the Research Center for Internet Psychology at the Sammy Ofer School of Communications, the Interdisciplinary Center in Herzliya, Israel. His book Technology and Psychological Well-being is published by Cambridge University Press