When using 3rd party libraries/components in production projects, are you rigorous about using only released versions of said libraries?
When do you consider using a pre-release or beta version of a library (in dev? in production, under certain circumstances)?
If you come across a bug or shortcoming of the library and you're already committed to using it, do you apply a patch to the library or create a workaround in your code?
I am a big fan of not coding something when someone else has a version that I could not code in a reasonable amount of time or would require me to become an expert on something that wouldn't matter in the long run.
There are several open source components and libraries I have used in our production environment such as Quartz.NET, Log4Net, nLog, SharpFTPLibrary (heavily modified) and more. Quartz.NET was in beta when I first released an application using it into production. It was a very stable beta and I had the source code so I could debug an issue and there were a few. When I encountered a bug or an error I would fix it and post the issue to the bug tracker or author. I feel very comfortable using a beta product if the source is available for me to debug any issues or there is a strong following of developers hammering out any issues.
I've used beta libraries in commercial projects before but mostly during development and when the vendor is likely to release a final version before I finish the product.
For example, I developed a small desktop application using Visual Studio 2005 Beta 2 because I knew that the RTM version would be available before the final release of my app. Also I used a beta version of FirebirdSQL ADO.NET Driver during development of another project.
For bugs I try to post complete bug reports whenever there's a way to reproduce it but most of the time you have to find a workaround to release the application ASAP.
Yes. Unless there's a feature we really need in a beta version.
There's no point using a beta version in dev if you aren't certain you'll use it in production. That just seems like a wasted exercise
I'll use the patch. Why write code for something you've paid for?
There's no point using a beta version in dev if you aren't certain you'll use it in production. That just seems like a wasted exercise
Good point, I was also considering the scenario of evaluation of the pre-release version in dev, but I supposed that taints the dev -> test/qa -> prod path.
I'll use the patch. Why write code for something you've paid for?
What if it's not a commercial library, but an open source one? What if the patch to be applied is not from the releasing entity (e.g. your own patch)?
I use:
Infragistics (.NET WinForms controls)
LeadTools (video capture)
Xtreme ToolkitPro (MFC controls)
National Instruments Measurement Studio (computational libraries, plotting, and DAQ)
I've found significant bugs in every one of these, so I try to limit their use as much as possible. Infragisitcs is pretty good for what it is, and National Instruments is by far the best, although quite limited. I would avoid LeadTools at all cost.
Related
I decided lately to move from Eclipse ADT to the latest AS version.
The first weird thing that I've noticed is that when I create a new project, it is always based on the Android support library even though I selected the minimum SDK to be level 19.
What is the reason for that?
Is there a way to configure it otherwise?
The reason for this is mainly backward compatibility. Right now, you may want to make your app for API19+, but later you may decide to lower it a bit down to support more devices, and you shouldn't be having problems with that, if you use support library.
There's also the thing that support library gets updated much more often than Android core library, therefore, if you base your project on it, it should be pretty much bug free.
One more thing, if you extend activity compat for example, the activity checks what version of Android you are currently having on your device and uses core features automatically if available, so it's good for you in many ways to use support library :)
I am wondering what level of support the latest MonoTouch has for using SQLite. The closest information I can find is this article here which referes to limited support in v1.2 however it concedes that you may run into run time errors while using this.
This is what I found on the Xamarin website: http://docs.xamarin.com/ios/Guides/Advanced_Topics/System.Data
This really scares me. Is there any documentation out there indicating what current level of support Xamarin has for SQLite?
I can't speak about the changes in System.Data support past that article, but I think it's quite common for folks to use csharp-sqlite, or better yet sqlite-net instead. Csharp-sqlite is an independent port of SQLite. And sqlite-net is "better yet" in the sense that its a minimal library where you can drop a single file in your project and use it to support sqlite on the various mono platforms. Yet it has nice features still such as "strongly typed queries" due to reflection-based ORM. So if you don't need a full Sqlite driver its a good option.
Greg Shackles did a nice seminar on x-platform dev with Monotouch/droid back in April where he covers these and other libraries: http://blog.xamarin.com/2012/04/25/cross-platform-mobile-development-seminar/
This link is outdated, it's about MonoTouch 1.2 and the latest MonoTouch's version is 6.0.
I'm using Sqlite with Vici CoolStorage in two apps on App Store: easy and no problems at all. I've never see any runtime errors using Sqlite.
Hi I have a Windows OS and I currently have the most up to date version of Node.JS running (which includes npm). I would really like build and compile 0.1.91 which can be found here http://nodejs.org/dist/. I'm extremely new to this and any all help would be greatly appreciated.
Node first supported native Windows builds in the .5 dev branch. To make it happen, they had to rewrite many internals from scratch – the platform compatibility layer now exists as libuv.
Before that, you had to build Node under Cygwin. I remember building .4 in Windows with Cygwin, and it was a complete pain. The GitHub wiki has since pulled down all Cygwin-related information since it's no longer relevant. (If you really want to see how Cygwin builds were done, I suppose you could clone the wiki's repo and go digging around. The information isn't available online anymore.)
Support for building on Windows with Cygwin wasn't added until 0.1.98, and support was dropped with .6. So, the specific version you're trying to build won't work.
At any rate, it's a very bad idea to run very old software, especially something like Node 0.1, which was still very early in its development. It's nearly guaranteed to be full of security holes.
I have a project built around Subsonic 3.0.0.3 and have run into the dreaded medium trust issue, can anyone tell me is there a way I can mod the code myself to get this working or what the expected timescale for 3.1 version is? Its looking increasingly like I will have to ditch subsonic to get my system running
Regards
Mike
No timeframe for SubSonic 3.1 (or 3.0.0.4), but here are the current plans: http://groups.google.com/group/subsonicproject/browse_thread/thread/caae09418ce4d975/
The SubSonic Google discussion group is the best place to find out about the current development happenings for SubSonic.
Short answer, as soon as possible.
Long answer, there's a number of things planned for 3.1 these include (but are not necessarily limited to):
Oracle support
MediumTrust support
Automatic mapping of collections in SimpleRepository
These are all in development right now but before they become the main focus we need to get version 3.0.0.4 out the door with fixes for a lot of the outstanding issues listed on github. There's also a lot of more boring work going on behind the scenes which should make regular and stable releases easier.
The current release schedule is:
Version 3.0.0.4 - 22nd March 2010
Version 3.1 - 22nd May 2010
Pretty straightforward question here: I like tools such as FxCop when it comes to scanning assemblies to get better insight into my code, and would like to start doing it on C# 4.0 assemblies. Any out there yet, or should I sit tight for a few more months while it's released and tools are updated?
What about Microsoft StyleCop for Visual Studio 2010?
The VS2010 beta includes a newer version of Code Analysis, which runs FxCop during the build process and displays the output as warnings. See the Code Analysis tab of project properties.
However, it's only available in the Premium and Ultimate editions. (See comparison)
I really wish that Microsoft would include it in the Express Editions and enable it by default for all projects; that might substantially improve beginner code.
The tool NDepend supports C#4, and even now C#5. It integrates inside Visual Studio 2012, 2010 and 2008. Disclaimer: I am one of the developers of the tool
The tool propose many facilities for your need of scanning assemblies to get better insight into my code, like Dependency Graph, Dependency Matrix, Code Metrics, Code Diff capabilities...
If you like FxCop, then you'll find useful the NDepend possibility to write Code Query and Code Rule over LINQ Queries (namely CQLinq). More than 200 CQLinq code queries and rules are proposed by default.
It is easy to write your own ones or customize existing ones. CQLinq queries are compiled and executed instantly and their results are presented in a browsable-friendly way, see the screenshot below:
The SD C# Clone Doctor statically analyzes C# (yes, even version 4.0) source code for duplication.
The CloneDR can be applied to large scale software systems, and typically finds 10-20% duplicated code.
There is a sample clone report at the link.