Great!  Sounds like Chris and I both learned something.  I was surprised to see the possibility of this being off come up--given the great effort the Core Team has put into running in more secure environments...  (I certainly didn't mean to sound unappreciative, jsut surprised.)

Option Strict On makes a more hopeful case for Mono compilation... 

thecrispy1 wrote:

We do not have Option Strict On everywhere.  The reason is it would require some 'catch up' time which would have to be prioritized.  I defintaly feel everything should have Option Strict On, but it takes time to implement.  We have discussed this before along with other changes and it is a matter of what is the best time to do it.  You may say "it should have been done already, or stop everything and do it now" but that is a matter of preference.  Web farm support or option strict on, which do you find more important?

If the core team faces choices like this regularly them maybe it is time to expand the core team?
If the coreteam must think like this, for me that is like putting out fires. And that will get back to haunt you sooner or later. I know it will be though to expand because of the nature of open source, but maybe a thought anyway?

The core team faces many choices on a weekly basis.  Adding more people will not make decisions come any easier. We were once only 30 and now we are around 42 and things are not any easier.  Adding more people to just the core team is not the answer, trust me.

But...

Dividing it into sub-projects and adding people to the subprojects may be.  We are already taking applications for the Forums/Blogs and gallery subprojects.  There will be more to follow after the 3.1 release.

sry 4 taking this offtopic.....

dividing it into sub-projects are a good start I think.

with good managment skills and good management tools adding more people just might prove to be both needed and the right way. O/c a bigger coding circle will need more heavy managment then a smaller one, but if you peak at many of the big corporations they have planty of developers coding. and yes  i relize Dnn being o-source, and people contribute for free but the same priciples apply to your project as well as any project of a certain size. Good managment skills and project skills are needed. And from what you all have achived so far I would say Dnn has both.

Looking forward to next release. You are all doing great

~ Option Strict has been a "coding standard" since version 1.0.9... however, enforcement of our own standards is always difficult in a highly distributed and quick moving project.  We periodically slow things down to catch up on things like this if/when they get overlooked.  OS is simply an easy case to observe... there are many examples of coding standards that we wish to use but do not always... we are constantly on the lookout for good tools to help us enforce more esoteric development standards.  Thats not always easy... consider use of correct case in SQL.

~ Management of the OS project is challenging and fun.  To be sure, we could benefit from more structured management techniques.  Both Shaun and I come from backgrounds heavily versed in continuous improvement and project management (read PMI, CMM, etc).  However, the real world of open source and community driven software development presents challenges that are not only different from those in a closed environment, but also almost "unimagineable".

One very simple example is just management of a traditional critical path (where a delivery date is determined by the a path of dependencies).  Invariably that critical path changes daily because our resources become constrained, priorities are adjusted, new priorities are introduced, etc.  Yes, these are fairly normal issues (even in closed environments) however it is the relative instability which is different.  In most environments, project management handles these kinds of issues by "padding" or introducing contingency within a plan (say 10-20%).  But in this kind of environment that contingency can become much greater (50-100% or more).

Will the team grow?  It will change first... it will grow overall, but partly through the identificaction of new ways to participate.  Our first priority in this area (as you have ascertained) is to shorten the overall schedules (thus the critical paths) by breaking things apart.  So while we have not yet addressed the root of the issue, we are changing things such that the issues have less impact (e.g. 50% variance on a small piece has less impact than 50% variance on the whole thing all together).

Cheers,
Scott

lol.  Joe thanks for the laugh.

Appreciated :)

Rather than bear the expense and humiliation of a dominatrix, I've taken it upon myself to get Mr. Harvey's C# port to run under Darwin BSD on the Mac's OSX 10.3. It's just as painfully satisfying, and involves fewer virii.

The good news is, it "almost" works.  I've only had to tweak the XMLLoggingProvider to make a few left-leaning slashes lean to the right, and most of the headache was in the Mono/XSP/httpd.conf configuration(s).

Below are the two damnnearworkingbutnotquiteyet scenarios.  I post them because:
- I know somebody else is out there, as unshaven and disheveled as I, and you should know you're not alone.  Put down the knife; and
- There's a chance one or more of you ran into similar problems during normal setup and operation, and maybe you have a quick fix

I. Connecting to a new (empty) database:
-Client connects to server successfully
-Server connects to database successfully
-DNN reroutes to "Install" routines successfully
Problem: Browser/Client get stuck in Continual-Loop-boogie until the resources are exhausted
Description: Error processing request.

Error Message: HTTP 500.

Stack Trace:

System.IO.IOException: Too many open files <=CLICK FOR MORE INFO
in <0x004ec> System.IO.Directory:GetFileSystemEntries (System.String path, System.String pattern, FileAttributes mask, FileAttributes attrs)
in <0x00024> System.IO.Directory:GetFiles (System.String path, System.String pattern)
in <0x0008c> System.Web.UI.TemplateParser:AddAssembliesInBin ()
in <0x00480> System.Web.UI.TemplateParser:.ctor ()
in <0x00020> System.Web.UI.ApplicationFileParser:.ctor (System.String fname, System.Web.HttpContext context)
in <0x00048> System.Web.UI.ApplicationFileParser:GetCompiledApplicationType (System.String inputFile, System.Web.HttpContext context)
in <0x0004c> System.Web.HttpApplicationFactory:CompileApp (System.Web.HttpContext context)
in <0x0005c> System.Web.HttpApplicationFactory:InitializeFactory (System.Web.HttpContext context)
in <0x000b8> System.Web.HttpApplicationFactory:GetInstance (System.Web.HttpContext context)
in <0x00158> System.Web.HttpRuntime:InternalExecuteRequest (System.Web.HttpWorkerRequest request)

II.  Connecting to an existing database:
- Client connects to server successfully, followed by a misleading 500.htm page warning:

The Assembly Version ( [ASSEMBLYVERSION] ) does not match the Database Version ( [DATABASEVERSION] )

ERROR: Could not connect to database.

Index is less than 0 or more than or equal to the list count. Parameter name: index 0  <=CLICK FOR MORE INFO

I'm sort of hoping that somebody might have a workaround to tweak the existing db and portalsettings.cs(or vb) to circumvent the exception.  Right now I don't care that it can't compile in the *NIX environment.  We just need it to run...

Thanks, as always, in advance.

-jjg

JWhite wrote:

We host our own source code server.  No, the repository is not open for anonymous read-only access at this time.

Jeff_K wrote:

... the C#-port types might go play quietly if there was an open subversion repository...

Heyyyy... who you callin' subversive?

-jjg

slope wrote:

@RusselH What do you intend to do with the DnnC# codebase? Will you make it public, and asign groups to work with it, checking for bugs or are you using it for a special project of your? There have been so many points made by both camps here that I start feeling it is about time to look at the end product. Let's know if you are sharing this.