I recommend that you sign up for this mailing list. If you run into any trouble with it on FreeBSD, these people will help you out pretty fast.

Also, you mentioned in another thread that you want to use generics. guess what? mono already has support for generics! It's alpha, but i've been using it with no problems. You can even install mono on your windows development box and use it, if you must stay on windows :P

Quote:

Original post by wolfman8k Also, you mentioned in another thread that you want to use generics. guess what? mono already has support for generics! It's alpha, but i've been using it with no problems. You can even install mono on your windows development box and use it, if you must stay on windows :P

Oh I know that mono is already supporting much of the generics with C#.. and I have heard some great things about it.

For this project I did not need generics, as I used C# mostly as a scripting language for the server, I did not run into problems.

What I wanted the use of generics for was in C# and Managed DirectX projects, where I really need the generics support. I may actually try out mono on Windows tonight and see how my test rendering code works with generics.

Quote:

Original post by Anonymous Poster You say you recompile the code using Code dom How du you unload the ould code?. using .net as an Scripting host issent that good today as if you compile a newe version of the assambly the old version stays in merory. You can onely unload code if it is in a nother code dom. but comunicate beween code doms is like cominication beween prozesses. Can you pleas explain how you managet to avoid this problems ?

Wow sorry I didn't see this last post at all, my apologies for taking so long to reply.

Well this was actually one of the largest problems I had when building my framework, because obviously .NET does not allow for unloading assemblies from the AppDomain because of issues with managed code (ie it truly isn't a managed system if you could just pull assemblies out).

What I did was use multiple AppDomains, as is recommended by Microsoft if you really do need to unload assemblies. As stated by numerous Microsoft developers, the ability to unload assemblies either will not be put into the system, or if it is than it requires some major work being done and would be in a major .NET release.

I found a post by Stephen Styrchak elsewhere and he posted what he used for basic script-engine code with dynamic AppDomain, and I went from there designing and building the system with multiple AppDomains.

Here is the code he posted:

public class MyApplication{
public static void Main(){
AppDomain appDomain = null;
AppDomainSetup setup = new AppDomainSetup();
//TODO: customize settings for the remote AppDomain.
try {
// Create a remote AppDomain to do compilations in
appDomain = AppDomain.CreateDomain("VsaDomain", null, setup);

// Instantiate my VSA host object in the remote AppDomain. This
// reduces the number of cross-appdomain calls and also I do not
// want to call IVsaEngine.Assembly from here because that defeats
// the purpose of the remote AppDomain.
AssemblyName assemblyName =
Assembly.GetAssembly(typeof(MyVsaHost)).FullName;
MyVsaHost host = (MyVsaHost)(appDomain.CreateInstance(assemblyName,
"MyVsaHost").Unwrap());
host.Run(args);
}catch (Exception e) {
//TODO: handle errors
}finally{
// Unload the remote AppDomain now that we're done with it.
if (appDomain != null)
AppDomain.Unload(appDomain);
}
}
}

public class MyVsaHost{
public void Run(){
//TODO: create a VSA engine and operate on it
}
}

I won't claim to know much about what you guys are talking about but what I do know about is DB's and DB management, and I will tell you this, if it comes between MSsql or Mysql Postgres will take them both hands down any day of the week and twice on sundays.
If you are planning on ever having more than 100-200 concurrent connections to your DB then postgres is the only option as it handles concurrent connections so much more efficiently than any other DB it isn't even funny.

Quote:

Original post by netflow I won't claim to know much about what you guys are talking about but what I do know about is DB's and DB management, and I will tell you this, if it comes between MSsql or Mysql Postgres will take them both hands down any day of the week and twice on sundays. If you are planning on ever having more than 100-200 concurrent connections to your DB then postgres is the only option as it handles concurrent connections so much more efficiently than any other DB it isn't even funny.

I would never use mySQL for obvious reasons, but I object to saying Postgres is a more competant DB than MS SQL. Both MS SQL and Postgres are amazing DB systems, but I would still rank MS SQL higher on an enterprise level, especially once you pass the 100GB mark.

There are pros and cons to both of those RDBMS packages.

Why would you ever have 200 connections to your database? You're using an application server in front of the database, right? If not, well, there's no saving you :-)

We looked at a number of databases, and ended up with MySQL for performance and operational reasons. PGSQL was out of the running, because it doesn't currently spool roll-forward logs. This means that you can only ever restore the database to the point of your last consistent back-up; if you lose your table space, you can't restore the table space from backup and then roll forward to the point of crash using the logs.

That's a pretty major limitation for an online, high-availability transactional system!

Quote:

Original post by hplus0603 Why would you ever have 200 connections to your database? You're using an application server in front of the database, right? If not, well, there's no saving you :-)

LOL I was actually going to say this myself but just figured there may be some wierd out of the way kind of application that would require this for some reason.

I really can't think of any sane reason to have 200 connections to a single RDBMS server though.