I wholeheartedly agree about the importance of source control, even though my specific advice didn't really involve that.
To the OP in particular: How do you plan to statically link your new library into multiple projects? Are you planning to make a copy of the code files for each C# project that uses Sqlite? I don't think you'll be able to do this for assemblies written in any other language, e.g. VB.NET. In fact, people using these languages are basically locked out of your library, at least without a wrapper to make it a DLL (I think). Also, this approach (making copies of the code) introduces parallel maintenance issues, esp. if you end up with multiple copies of the library on your own computer. I guess the existence of parallel copies is acceptable - even desirable - under some circumstances, I just wonder if you've considered these issues. There is also the "Add as Link" feature, which is similar to #include in C++. I have never worked through all of the issues re. source control and "Add as Link," although I suspect this can be made to work. I don't mean to defy your disclaimer; these are topics of some practical importance to me. I deal with C++ / Sqlite apps daily that may eventually need to be (rapidly) transitioned to C#. My growing sentiment is that .NET does not really lend itself to this... I guess I want "#include" from C++. Another area I miss "#include" is in declaring simple constants; should two different assemblies that, say, both need to know that WAKEUP_STRING means "~~~WTFU~~~" really have to use some kind of DLL or IPC mechanism at runtime to ascertain this fact? Or should they have parallel copies of, say, Contants.cs? Or should we use "Add as Link" and kludge around source control? I wonder if Microsoft really thought these things through, especially since it is there source control tool that so greatly mishandles "Add as Link." Maybe you or someone else can dispel my confusion on these points. Someone once suggested to me that the best answer is to select "~~~WTFU~~~" (or whatever) from a "constants" table in a database. That seems like an arbitrary and unwelcome requirement, although if this really must be done, Sqlite might be the way to go. ________________________________________ From: sqlite-users-boun...@sqlite.org [sqlite-users-boun...@sqlite.org] On Behalf Of Roger Binns [rog...@rogerbinns.com] Sent: Thursday, July 09, 2009 12:29 PM To: General Discussion of SQLite Database Subject: Re: [sqlite] Pros and cons of various online code sharing sites -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Noah Hart wrote: > I have looked at sourceforge, googlecode, codeproject and a few others. > However, while they all look fine, I not sure what works well in the real > world. TL;DR: Being familiar with DVCS is an important developer skill these days. Concentrate on that. I'd recommend Google Code, BitBucket and then SF. I can't speak for codeproject but can for the others. Google code only allows a small subset of licenses (a good thing) but doesn't include public domain which is what SQLite itself is. Google's mailing lists are the best. SF has horrendous mailing lists and web interface. SF has over the last year or so added every bell and whistle imaginable (wikis, bug trackers, trac etc). What I would recommend is that you also take this as an opportunity to learn how to use a DVCS. The main players are git, mercurial and bzr and you'll get adherents coming out of the woodwork for each, but they are all far more similar than they are different. Unless you love all things Ubuntu, I'd recommend starting with mercurial and once comfortable with it try out git to get a different perspective. SF and GoogleCode both support mercurial, and there is a dedicated mercurial based hoster at http://www.bitbucket.org http://hgbook.red-bean.com/ Roger -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkpWKQIACgkQmOOfHg372QRgMQCbBGWsCD0t2GwotjeWaPJOzcTA LykAniJas2Yy/iemeVyuma6kxRwrfui2 =kExD -----END PGP SIGNATURE----- _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users The information contained in this e-mail is privileged and confidential information intended only for the use of the individual or entity named. If you are not the intended recipient, or the employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any disclosure, dissemination, distribution, or copying of this communication is strictly prohibited. If you have received this e-mail in error, please immediately notify the sender and delete any copies from your system. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
