So we've got a nifty open-source program now. Neat! But... what should we do? I'm trying to fix the build right now so it works out of the box. I'm getting complaints about SQLite. I suspect Kyle accidentally installed it to the GAC at some point and has forgotten he did so. Also I rather suspect we don't need both the SQLite dlls and the SQLite source built into the solution; one or the other should be plenty (I recommend the dlls).
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I didn't realize the SQLite DLLs were breaking the build - but Details Ripper isn't something that's distributed. Those SQLite dlls will cause problems if we use those in the product, and are only there for the tool projects. It would probably be better if they were gone altogether.
I've got a little bit of cleanup I need to do before making the code accessible to the general public as a GPL app.
My main goals here are to have resources to:
Fixing ongoing bugs
Maintain Game DBs
Finish iPad Application
Add features
Improve application architecture
There are several vestigial pieces of the application here you'll see, some parts that I was never able to get working well enough to ship and are in a half-finished mode. I simply chose to put the last working version of what I keep in my Perforce depot online.
From: Paul Zagieboylo [mailto:zahariel@users.sf.net]
Sent: Saturday, April 21, 2012 12:31 AM
To: [combatmanagerpf:discussion]
Subject: [combatmanagerpf:discussion] So... welcome to Combat Manager?
So we've got a nifty open-source program now. Neat! But... what should we do? I'm trying to fix the build right now so it works out of the box. I'm getting complaints about SQLite. I suspect Kyle accidentally installed it to the GAC at some point and has forgotten he did so. Also I rather suspect we don't need both the SQLite dlls and the SQLite source built into the solution; one or the other should be plenty (I recommend the dlls).
NuGet has a package provider for the x86 and x64 managed .NET versions of SQLite, and is fairly easy to tie into a project. Then, if you don't have the third party DLL on your machine, NuGet will go and fetch it for you. (AvalonDock is another 3rd party package that has an official NuGet deployment.) The only downside of SQLite is having to choose between x86 and x64 when you specify the reference package. (Which can make it a bit difficult on you if you have an x86 debug for edit-and-continue and then use an x64 release mode.) CombatManagerCore appears to be heavily dependent upon SQL_Lite, but if we spent some time cleaning it up then the Mono version of SQLite and the packaged version will have a lot of code consolidation (the primary difference being the namespace, and we can put in a namespace alias to handle that).
I don't know if you've had a chance to mess around with NuGet, but it's got quite a selection of packages. I always check NuGet for an existing official package when I'm looking for a popular library that I want to integrate into my C# apps.
Your call, but I can go through and convert the SQL_Lite calls into managed SQLite calls and compile the MonoTouch version and make sure I didn't break that.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The SQLite stuff in there is my doing. If the NuGet library can handle correctly placing the right architecture in the GAC, then it's worlds better than my hack. I'm not familiar with it, so I'd have to bow to your knowledge of it.
I'd just be wary of cross application issues. Every few weeks it seems there's someone with an issue using the official SQLite package float across the sqlite-users mailing list caused by an application that puts the 32 bit SQLite library on a machine and makes life difficult for 64 bit apps (or vice versa). I'm sure all of that can be solved by someone that knows what they're doing.
NuGet has a package provider for the x86 and x64 managed .NET versions of SQLite, and is fairly easy to tie into a project. Then, if you don't have the third party DLL on your machine, NuGet will go and fetch it for you. (AvalonDock is another 3rd party package that has an official NuGet deployment.) The only downside of SQLite is having to choose between x86 and x64 when you specify the reference package. (Which can make it a bit difficult on you if you have an x86 debug for edit-and-continue and then use an x64 release mode.) CombatManagerCore appears to be heavily dependent upon SQL_Lite, but if we spent some time cleaning it up then the Mono version of SQLite and the packaged version will have a lot of code consolidation (the primary difference being the namespace, and we can put in a namespace alias to handle that).
I don't know if you've had a chance to mess around with NuGet, but it's got quite a selection of packages. I always check NuGet for an existing official package when I'm looking for a popular library that I want to integrate into my C# apps.
Your call, but I can go through and convert the SQL_Lite calls into managed SQLite calls and compile the MonoTouch version and make sure I didn't break that.
I bow to Scott's opinion of your opinion. If you get an SQLite situation where we can use nearly identical code on Windows and Mono I would be happy. We just need to avoid a situation where a good percentage of users can't run the app because of other apps installed on the system as Scott suggests below.
From: Scott Seligman [mailto:seligman@users.sf.net]
Sent: Monday, June 04, 2012 9:54 PM
To: [combatmanagerpf:discussion]
Subject: [combatmanagerpf:discussion] Re: So... welcome to Combat Manager?
Personally, I'd go for it.
The SQLite stuff in there is my doing. If the NuGet library can handle correctly placing the right architecture in the GAC, then it's worlds better than my hack. I'm not familiar with it, so I'd have to bow to your knowledge of it.
I'd just be wary of cross application issues. Every few weeks it seems there's someone with an issue using the official SQLite package float across the sqlite-users mailing list caused by an application that puts the 32 bit SQLite library on a machine and makes life difficult for 64 bit apps (or vice versa). I'm sure all of that can be solved by someone that knows what they're doing.
NuGet has a package provider for the x86 and x64 managed .NET versions of SQLite, and is fairly easy to tie into a project. Then, if you don't have the third party DLL on your machine, NuGet will go and fetch it for you. (AvalonDock is another 3rd party package that has an official NuGet deployment.) The only downside of SQLite is having to choose between x86 and x64 when you specify the reference package. (Which can make it a bit difficult on you if you have an x86 debug for edit-and-continue and then use an x64 release mode.) CombatManagerCore appears to be heavily dependent upon SQL_Lite, but if we spent some time cleaning it up then the Mono version of SQLite and the packaged version will have a lot of code consolidation (the primary difference being the namespace, and we can put in a namespace alias to handle that).
I don't know if you've had a chance to mess around with NuGet, but it's got quite a selection of packages. I always check NuGet for an existing official package when I'm looking for a popular library that I want to integrate into my C# apps.
Your call, but I can go through and convert the SQL_Lite calls into managed SQLite calls and compile the MonoTouch version and make sure I didn't break that.
Wow, I think sourceforge ate the big post I had just put together. (Dang it!) Let's see if I can regurgitate it (I usually copy a message to clipboard before I hit Post because a lot of sites mess up. Didn't think Sourceforge would, but there ya go.)
We should avoid being directly dependent upon the GAC. If you just deploy everything your application needs into the same or nested folder of your application, any referenced assemblies (and interop DLLs) located there are higher priority than the GAC and you won't have conflicts with your GAC.
Regarding System.Data.SQLite vs. Mono.Data.Sqlite. Turns out that the names of the actual classes are different, too (casing only), so I was thinking we could just reference Mono.Data.Sqlite in the windows version as well. (Mono is binary compatible with .NET thanks to the greatness that is IL, and Mono.Data.Sqlite's only dependency is upon sqlite3.dll.) I've already switched it out in one of my apps to test it out, and it appears to work just fine. I would create a dependency folder and put the mono.data.sqlite.dll and sqlite3.dll in there so that no one has to worry about versioning and trying to find it again in the future.
The alternative to referencing Mono.Data.Sqlite isn't a pretty one, either. I would probably end up abstracting things out to delegates and base IDbConnection (IDbCommand, etc) interfaces.
I think I finally have a handle on how the dynamic database creation and accessing is working, so it shouldn't be too difficult to switch it out. I wanted to understand what all of that was doing before I started mucking around with code.
Any objections to using the Mono sqlite implementation in the Windows client?
(This post didn't go into as much detail as my original post, but I hit the important bits.)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I've already switched it out in one of my apps to test it out, and it appears to work just fine. I would create a dependency folder and put the mono.data.sqlite.dll and sqlite3.dll
I'm confused. You still need two native DLLs, unless you're going to limit CM to only run as a 32-bit executable on all platforms.
Any objections to using the Mono sqlite implementation in the Windows client?
None at all. Just make sure the resulting install can happily run on 64-bit machine when the main process is 32-bit or 64-bit.
From: Jason Seeley [mailto:jseeley150@users.sf.net]
Sent: Sunday, June 10, 2012 2:23 PM
To: [combatmanagerpf:discussion]
Subject: [combatmanagerpf:discussion] So... welcome to Combat Manager?
Wow, I think sourceforge ate the big post I had just put together. (Dang it!) Let's see if I can regurgitate it (I usually copy a message to clipboard before I hit Post because a lot of sites mess up. Didn't think Sourceforge would, but there ya go.)
We should avoid being directly dependent upon the GAC. If you just deploy everything your application needs into the same or nested folder of your application, any referenced assemblies (and interop DLLs) located there are higher priority than the GAC and you won't have conflicts with your GAC.
Regarding System.Data.SQLite vs. Mono.Data.Sqlite. Turns out that the names of the actual classes are different, too (casing only), so I was thinking we could just reference Mono.Data.Sqlite in the windows version as well. (Mono is binary compatible with .NET thanks to the greatness that is IL, and Mono.Data.Sqlite's only dependency is upon sqlite3.dll.) I've already switched it out in one of my apps to test it out, and it appears to work just fine. I would create a dependency folder and put the mono.data.sqlite.dll and sqlite3.dll in there so that no one has to worry about versioning and trying to find it again in the future.
The alternative to referencing Mono.Data.Sqlite isn't a pretty one, either. I would probably end up abstracting things out to delegates and base IDbConnection (IDbCommand, etc) interfaces.
I think I finally have a handle on how the dynamic database creation and accessing is working, so it shouldn't be too difficult to switch it out. I wanted to understand what all of that was doing before I started mucking around with code.
Any objections to using the Mono sqlite implementation in the Windows client?
(This post didn't go into as much detail as my original post, but I hit the important bits.)
Okay, sorry, I had kind of thought that Combat Manager wouldn't be needing more than 4gb RAM, so I hadn't considered a 64-bit release target. The debug was set as x86, the installer was set as x86, and I didn't look at Release (which I see now that it is set to Any CPU). So if we keep that as Any CPU, then yes, we'd have to have the installer dynamically put the appropriate DLL into the application install folder. It's been a while since I've messed with it (the only time I have was with a program that interacted with a custom USB device and needed drivers installed). It seems to me that it was a "Condition" that can be set for a file to be installed or not based on x86 or amd64. If the goal is to support 64-bit as actual 64-bit (rather than 32-bit) then I'll make the necessary installer changes. I have to modify the installer anyway. :)
As far as having the compiler plop the proper Sqlite3.dll into the output folder, though, I'm not sure. We can assume 64-bit as far as the build goes (since all of the developers are likely on 64-bit machines) and the installer would take care of it for deployment to other people.
I'm relatively new to Git (I've been using SVN for the past several years, and other stuff before that), but my plan would be to create a branch that I can push to you so you can review it before it goes out to everyone else.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
Personally, I'd prefer if we kept the same mechanism that's in place now. Namely: Picking the native architecture at run time, not install time. It solves issues caused by people copying the post-install bits around. Granted, it's not much of a case to worry about, but if it can be solved, we might as well solve it.
If you could try out the version of Mono's SQLite engine at http://scottandmichelle.net/temp/mono_sqlite.zip , it'd be most appreciated. It's largely untested, but it should be a drop in replacement for the standard Mono stuff, and will happily run on any platform with all three DLLs present. If it works, it should simplify the installation a bit.
Let me know how it goes.
From: Jason Seeley [mailto:jseeley150@users.sf.net]
Sent: Sunday, June 10, 2012 5:29 PM
To: [combatmanagerpf:discussion]
Subject: [combatmanagerpf:discussion] Re: So... welcome to Combat Manager?
Okay, sorry, I had kind of thought that Combat Manager wouldn't be needing more than 4gb RAM, so I hadn't considered a 64-bit release target. The debug was set as x86, the installer was set as x86, and I didn't look at Release (which I see now that it is set to Any CPU). So if we keep that as Any CPU, then yes, we'd have to have the installer dynamically put the appropriate DLL into the application install folder. It's been a while since I've messed with it (the only time I have was with a program that interacted with a custom USB device and needed drivers installed). It seems to me that it was a "Condition" that can be set for a file to be installed or not based on x86 or amd64. If the goal is to support 64-bit as actual 64-bit (rather than 32-bit) then I'll make the necessary installer changes. I have to modify the installer anyway. :)
As far as having the compiler plop the proper Sqlite3.dll into the output folder, though, I'm not sure. We can assume 64-bit as far as the build goes (since all of the developers are likely on 64-bit machines) and the installer would take care of it for deployment to other people.
I'm relatively new to Git (I've been using SVN for the past several years, and other stuff before that), but my plan would be to create a branch that I can push to you so you can review it before it goes out to everyone else.
I got it all working with the 32-bit Mono.Data.Sqlite. Dropped the one you sent and it works great in both 32-bit and 64-bit. Thank you for finding / creating that for me. I'm all for keeping the install easy (I can't say that I've ever enjoyed making installers).
Next up, I need to run it in MonoTouch and see how well it works. I understand that in MonoTouch all of the fields are strings, which is not the case with the desktop version, so I need to test it.
However, I have a big deploy tomorrow morning at 5am so I'm done for tonight. :)
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
From: Jason Seeley [mailto:jseeley150@users.sf.net]
Sent: Sunday, June 10, 2012 9:09 PM
To: [combatmanagerpf:discussion]
Subject: [combatmanagerpf:discussion] Re: So... welcome to Combat Manager?
I got it all working with the 32-bit Mono.Data.Sqlite. Dropped the one you sent and it works great in both 32-bit and 64-bit. Thank you for finding / creating that for me. I'm all for keeping the install easy (I can't say that I've ever enjoyed making installers).
Next up, I need to run it in MonoTouch and see how well it works. I understand that in MonoTouch all of the fields are strings, which is not the case with the desktop version, so I need to test it.
However, I have a big deploy tomorrow morning at 5am so I'm done for tonight. :)
I haven't forgotten about this. I'm new to Git and I want to make a local branch to commit it to, and then push that branch up for review so that I'm not messing with the master. From what I understand, I can really mess things up with Git if I do it wrong. I'm going to try to get it all figured out this week.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
I have committed a branch called MonoSqlite. Can someone else pull it down, and compile and run it to make sure I got everything included that needs to be? (I'm still getting used to git, and I'm not used to command-line commits.)
I haven't tested it on MonoTouch yet. I'll be sucking the code over to my mac presently, and figuring out how to build it over there.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
So we've got a nifty open-source program now. Neat! But... what should we do? I'm trying to fix the build right now so it works out of the box. I'm getting complaints about SQLite. I suspect Kyle accidentally installed it to the GAC at some point and has forgotten he did so. Also I rather suspect we don't need both the SQLite dlls and the SQLite source built into the solution; one or the other should be plenty (I recommend the dlls).
Thanks for the work. I appreciate this.
I didn't realize the SQLite DLLs were breaking the build - but Details Ripper isn't something that's distributed. Those SQLite dlls will cause problems if we use those in the product, and are only there for the tool projects. It would probably be better if they were gone altogether.
I've got a little bit of cleanup I need to do before making the code accessible to the general public as a GPL app.
My main goals here are to have resources to:
Fixing ongoing bugs
Maintain Game DBs
Finish iPad Application
Add features
Improve application architecture
There are several vestigial pieces of the application here you'll see, some parts that I was never able to get working well enough to ship and are in a half-finished mode. I simply chose to put the last working version of what I keep in my Perforce depot online.
From: Paul Zagieboylo [mailto:zahariel@users.sf.net]
Sent: Saturday, April 21, 2012 12:31 AM
To: [combatmanagerpf:discussion]
Subject: [combatmanagerpf:discussion] So... welcome to Combat Manager?
So we've got a nifty open-source program now. Neat! But... what should we do? I'm trying to fix the build right now so it works out of the box. I'm getting complaints about SQLite. I suspect Kyle accidentally installed it to the GAC at some point and has forgotten he did so. Also I rather suspect we don't need both the SQLite dlls and the SQLite source built into the solution; one or the other should be plenty (I recommend the dlls).
Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/combatmanagerpf/discussion/general/
To unsubscribe from further messages, please visit https://sourceforge.net/auth/prefs/
NuGet has a package provider for the x86 and x64 managed .NET versions of SQLite, and is fairly easy to tie into a project. Then, if you don't have the third party DLL on your machine, NuGet will go and fetch it for you. (AvalonDock is another 3rd party package that has an official NuGet deployment.) The only downside of SQLite is having to choose between x86 and x64 when you specify the reference package. (Which can make it a bit difficult on you if you have an x86 debug for edit-and-continue and then use an x64 release mode.) CombatManagerCore appears to be heavily dependent upon SQL_Lite, but if we spent some time cleaning it up then the Mono version of SQLite and the packaged version will have a lot of code consolidation (the primary difference being the namespace, and we can put in a namespace alias to handle that).
I don't know if you've had a chance to mess around with NuGet, but it's got quite a selection of packages. I always check NuGet for an existing official package when I'm looking for a popular library that I want to integrate into my C# apps.
Your call, but I can go through and convert the SQL_Lite calls into managed SQLite calls and compile the MonoTouch version and make sure I didn't break that.
<html><head></head><body bgcolor="#FFFFFF">
On Jun 4, 2012, at 7:43 PM, "Jason Seeley" <jseeley150@users.sf.net> wrote:
I bow to Scott's opinion of your opinion. If you get an SQLite situation where we can use nearly identical code on Windows and Mono I would be happy. We just need to avoid a situation where a good percentage of users can't run the app because of other apps installed on the system as Scott suggests below.
From: Scott Seligman [mailto:seligman@users.sf.net]
Sent: Monday, June 04, 2012 9:54 PM
To: [combatmanagerpf:discussion]
Subject: [combatmanagerpf:discussion] Re: So... welcome to Combat Manager?
Personally, I'd go for it.
The SQLite stuff in there is my doing. If the NuGet library can handle correctly placing the right architecture in the GAC, then it's worlds better than my hack. I'm not familiar with it, so I'd have to bow to your knowledge of it.
I'd just be wary of cross application issues. Every few weeks it seems there's someone with an issue using the official SQLite package float across the sqlite-users mailing list caused by an application that puts the 32 bit SQLite library on a machine and makes life difficult for 64 bit apps (or vice versa). I'm sure all of that can be solved by someone that knows what they're doing.
On Jun 4, 2012, at 7:43 PM, "Jason Seeley" jseeley150@users.sf.nethttp://sourceforge.net/../mailto:jseeley150@users.sf.net wrote:
NuGet has a package provider for the x86 and x64 managed .NET versions of SQLite, and is fairly easy to tie into a project. Then, if you don't have the third party DLL on your machine, NuGet will go and fetch it for you. (AvalonDock is another 3rd party package that has an official NuGet deployment.) The only downside of SQLite is having to choose between x86 and x64 when you specify the reference package. (Which can make it a bit difficult on you if you have an x86 debug for edit-and-continue and then use an x64 release mode.) CombatManagerCore appears to be heavily dependent upon SQL_Lite, but if we spent some time cleaning it up then the Mono version of SQLite and the packaged version will have a lot of code consolidation (the primary difference being the namespace, and we can put in a namespace alias to handle that).
I don't know if you've had a chance to mess around with NuGet, but it's got quite a selection of packages. I always check NuGet for an existing official package when I'm looking for a popular library that I want to integrate into my C# apps.
Your call, but I can go through and convert the SQL_Lite calls into managed SQLite calls and compile the MonoTouch version and make sure I didn't break that.
Sent from sourceforge.nethttp://sourceforge.net because you indicated interest in https://sourceforge.net/p/combatmanagerpf/discussion/general/
To unsubscribe from further messages, please visit https://sourceforge.net/auth/prefs/
Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/combatmanagerpf/discussion/general/
To unsubscribe from further messages, please visit https://sourceforge.net/auth/prefs/
Wow, I think sourceforge ate the big post I had just put together. (Dang it!) Let's see if I can regurgitate it (I usually copy a message to clipboard before I hit Post because a lot of sites mess up. Didn't think Sourceforge would, but there ya go.)
We should avoid being directly dependent upon the GAC. If you just deploy everything your application needs into the same or nested folder of your application, any referenced assemblies (and interop DLLs) located there are higher priority than the GAC and you won't have conflicts with your GAC.
Regarding System.Data.SQLite vs. Mono.Data.Sqlite. Turns out that the names of the actual classes are different, too (casing only), so I was thinking we could just reference Mono.Data.Sqlite in the windows version as well. (Mono is binary compatible with .NET thanks to the greatness that is IL, and Mono.Data.Sqlite's only dependency is upon sqlite3.dll.) I've already switched it out in one of my apps to test it out, and it appears to work just fine. I would create a dependency folder and put the mono.data.sqlite.dll and sqlite3.dll in there so that no one has to worry about versioning and trying to find it again in the future.
The alternative to referencing Mono.Data.Sqlite isn't a pretty one, either. I would probably end up abstracting things out to delegates and base IDbConnection (IDbCommand, etc) interfaces.
I think I finally have a handle on how the dynamic database creation and accessing is working, so it shouldn't be too difficult to switch it out. I wanted to understand what all of that was doing before I started mucking around with code.
Any objections to using the Mono sqlite implementation in the Windows client?
(This post didn't go into as much detail as my original post, but I hit the important bits.)
I'm confused. You still need two native DLLs, unless you're going to limit CM to only run as a 32-bit executable on all platforms.
From: Jason Seeley [mailto:jseeley150@users.sf.net]
Sent: Sunday, June 10, 2012 2:23 PM
To: [combatmanagerpf:discussion]
Subject: [combatmanagerpf:discussion] So... welcome to Combat Manager?
Wow, I think sourceforge ate the big post I had just put together. (Dang it!) Let's see if I can regurgitate it (I usually copy a message to clipboard before I hit Post because a lot of sites mess up. Didn't think Sourceforge would, but there ya go.)
We should avoid being directly dependent upon the GAC. If you just deploy everything your application needs into the same or nested folder of your application, any referenced assemblies (and interop DLLs) located there are higher priority than the GAC and you won't have conflicts with your GAC.
Regarding System.Data.SQLite vs. Mono.Data.Sqlite. Turns out that the names of the actual classes are different, too (casing only), so I was thinking we could just reference Mono.Data.Sqlite in the windows version as well. (Mono is binary compatible with .NET thanks to the greatness that is IL, and Mono.Data.Sqlite's only dependency is upon sqlite3.dll.) I've already switched it out in one of my apps to test it out, and it appears to work just fine. I would create a dependency folder and put the mono.data.sqlite.dll and sqlite3.dll in there so that no one has to worry about versioning and trying to find it again in the future.
The alternative to referencing Mono.Data.Sqlite isn't a pretty one, either. I would probably end up abstracting things out to delegates and base IDbConnection (IDbCommand, etc) interfaces.
I think I finally have a handle on how the dynamic database creation and accessing is working, so it shouldn't be too difficult to switch it out. I wanted to understand what all of that was doing before I started mucking around with code.
Any objections to using the Mono sqlite implementation in the Windows client?
(This post didn't go into as much detail as my original post, but I hit the important bits.)
Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/combatmanagerpf/discussion/general/
To unsubscribe from further messages, please visit https://sourceforge.net/auth/prefs/
Okay, sorry, I had kind of thought that Combat Manager wouldn't be needing more than 4gb RAM, so I hadn't considered a 64-bit release target. The debug was set as x86, the installer was set as x86, and I didn't look at Release (which I see now that it is set to Any CPU). So if we keep that as Any CPU, then yes, we'd have to have the installer dynamically put the appropriate DLL into the application install folder. It's been a while since I've messed with it (the only time I have was with a program that interacted with a custom USB device and needed drivers installed). It seems to me that it was a "Condition" that can be set for a file to be installed or not based on x86 or amd64. If the goal is to support 64-bit as actual 64-bit (rather than 32-bit) then I'll make the necessary installer changes. I have to modify the installer anyway. :)
As far as having the compiler plop the proper Sqlite3.dll into the output folder, though, I'm not sure. We can assume 64-bit as far as the build goes (since all of the developers are likely on 64-bit machines) and the installer would take care of it for deployment to other people.
I'm relatively new to Git (I've been using SVN for the past several years, and other stuff before that), but my plan would be to create a branch that I can push to you so you can review it before it goes out to everyone else.
Personally, I'd prefer if we kept the same mechanism that's in place now. Namely: Picking the native architecture at run time, not install time. It solves issues caused by people copying the post-install bits around. Granted, it's not much of a case to worry about, but if it can be solved, we might as well solve it.
If you could try out the version of Mono's SQLite engine at http://scottandmichelle.net/temp/mono_sqlite.zip , it'd be most appreciated. It's largely untested, but it should be a drop in replacement for the standard Mono stuff, and will happily run on any platform with all three DLLs present. If it works, it should simplify the installation a bit.
Let me know how it goes.
From: Jason Seeley [mailto:jseeley150@users.sf.net]
Sent: Sunday, June 10, 2012 5:29 PM
To: [combatmanagerpf:discussion]
Subject: [combatmanagerpf:discussion] Re: So... welcome to Combat Manager?
Okay, sorry, I had kind of thought that Combat Manager wouldn't be needing more than 4gb RAM, so I hadn't considered a 64-bit release target. The debug was set as x86, the installer was set as x86, and I didn't look at Release (which I see now that it is set to Any CPU). So if we keep that as Any CPU, then yes, we'd have to have the installer dynamically put the appropriate DLL into the application install folder. It's been a while since I've messed with it (the only time I have was with a program that interacted with a custom USB device and needed drivers installed). It seems to me that it was a "Condition" that can be set for a file to be installed or not based on x86 or amd64. If the goal is to support 64-bit as actual 64-bit (rather than 32-bit) then I'll make the necessary installer changes. I have to modify the installer anyway. :)
As far as having the compiler plop the proper Sqlite3.dll into the output folder, though, I'm not sure. We can assume 64-bit as far as the build goes (since all of the developers are likely on 64-bit machines) and the installer would take care of it for deployment to other people.
I'm relatively new to Git (I've been using SVN for the past several years, and other stuff before that), but my plan would be to create a branch that I can push to you so you can review it before it goes out to everyone else.
Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/combatmanagerpf/discussion/general/
To unsubscribe from further messages, please visit https://sourceforge.net/auth/prefs/
I got it all working with the 32-bit Mono.Data.Sqlite. Dropped the one you sent and it works great in both 32-bit and 64-bit. Thank you for finding / creating that for me. I'm all for keeping the install easy (I can't say that I've ever enjoyed making installers).
Next up, I need to run it in MonoTouch and see how well it works. I understand that in MonoTouch all of the fields are strings, which is not the case with the desktop version, so I need to test it.
However, I have a big deploy tomorrow morning at 5am so I'm done for tonight. :)
Great!
Thanks for your work on this!
From: Jason Seeley [mailto:jseeley150@users.sf.net]
Sent: Sunday, June 10, 2012 9:09 PM
To: [combatmanagerpf:discussion]
Subject: [combatmanagerpf:discussion] Re: So... welcome to Combat Manager?
I got it all working with the 32-bit Mono.Data.Sqlite. Dropped the one you sent and it works great in both 32-bit and 64-bit. Thank you for finding / creating that for me. I'm all for keeping the install easy (I can't say that I've ever enjoyed making installers).
Next up, I need to run it in MonoTouch and see how well it works. I understand that in MonoTouch all of the fields are strings, which is not the case with the desktop version, so I need to test it.
However, I have a big deploy tomorrow morning at 5am so I'm done for tonight. :)
Sent from sourceforge.net because you indicated interest in https://sourceforge.net/p/combatmanagerpf/discussion/general/
To unsubscribe from further messages, please visit https://sourceforge.net/auth/prefs/
I haven't forgotten about this. I'm new to Git and I want to make a local branch to commit it to, and then push that branch up for review so that I'm not messing with the master. From what I understand, I can really mess things up with Git if I do it wrong. I'm going to try to get it all figured out this week.
I have committed a branch called MonoSqlite. Can someone else pull it down, and compile and run it to make sure I got everything included that needs to be? (I'm still getting used to git, and I'm not used to command-line commits.)
I haven't tested it on MonoTouch yet. I'll be sucking the code over to my mac presently, and figuring out how to build it over there.