Been a while since I last posted on here. My aim to put up at least one worthwhile post every month seemed to fall by the wayside.
I still havent setup my old Acorn machine correctly yet, and cunningly my main desktop has decided it doesnt want to speak to my HDD any more.
Good news though, I have a new job that is very interesting to say the least and I have move house.
Bad news, totalled my bike and I have suffered from bad TV and travel karma over the last few weeks. But onwards and upwards! over the next few weeks I intend to put up at least one post concerning the Levenshtein Distance. There is lots of interesting proofs of concept out in the wild at the moment, but there are none concerning an actual useful example. I know that not everyone will be able to implement a really good peice of code to do this (and I doubt anything I produce will be class leading). But this is something I have to work on in my new job, so this will help me figure it out in my head :)
Wednesday, 14 April 2010
Saturday, 3 April 2010
Continuous Intergration
It's about time I started blogging about CI again, given that I have developed and worked with some of the best CI systems I have had the pleasure to encounter.
When I first got involved with CI it was with Java development. At the start we simply used Ant to carry out our builds and tests on remote servers. As time progressed, we started to look at some of the CI build tools that were available to us. We came across Cruisecontrol, which I think was the tool de jour when it came to build servers. I was naturally impressed with the features offered by Cruisecontrol at the time. We were able to put together a simple CI environment to carry out our builds and/or churns. As time progressed, we looked for ways to integrate Cruisecontrol into our main repository - the company I was working with at the time used Perforce as it's SCM, we also had a tool called the repository that held all of our application meta data (we made mobile phone apps, so the meta data was a collection of definitions per handset and carrier). By the time I left that company, we had almost a complete integration of our build environment with our repository and SCM.
From here, I moved to a .Net software house. I brought with me the concept of Cruisecontrol and CI. My new employers could be best described as a group of energetic younger people who worked on the bleeding edge. This time round, it wasn't mobile phone apps, instead it was the ultra serious realm of financial software. When I joined this company, the guys had just put the finishing touches to a migration to .Net, easy to implement but unforseen issues cropped up - that is a story for another day ;). These guys were up for anything when it came to CI and automated testing. I introduced them to Cruisecontrol and Ant for creating a CI build environment, the head of development (my boss) at the time was very interested in implementing a unit testing regime for the newly migrated .Net code. I remember working with an intern who had been tasked with creating a set of guidelines for unit testing within the integration code, this was about the time I started looking at Cruisecontrol.Net and Nant.
Given that my new place was a .Net house, it made little sense to me to implement a suite of Java based tools when there were viable .Net versions available. With this said and done, the company branched out into the new realms of .Net CI! It was a success from the get go, the upper management liked the idea of seeing nice graphs and reports on build status, the developers like the idea of being told when a specific build passed testing - it allowed pretty much anyone in the developer and analyst pool to see what was happening with their build and others.
I feel that good CI is often based on some simple foundations. First off would have to be good code. It doesn't matter if it doesn't pass the build at a lower level, those guys should be used to new build to go through some teething problems with production code, this is something that CI would come to reduce further down the line. Next, we needed a decent environment in which to build our code. At the start, we used Crusiecontrol.Net on one builds server, but we had another three servers available to us should we need them. As unit testing was rolled out for all of development, this allowed everyone to see problems before a build made it out onto a test environment. Naturally, this annoyed some developers who didn't see the point in unit testing their code, being in the build development team I could see the importance of unit testing and so could my colleagues. The next important thing that makes up a good CI environment is Software Configuration Management. I have worked with some excellent SCM's and some truly awful (read Visual Source Safe). At this point the company was using a tool called Surround (made by Seapine). It was a fairly good SCM, a little clunky and had some performance issues, we needed to move away from it however as we needed to get to a point where we could run multiple projects from a common library of assemblies. Surround wasn't really up to this. Being a .Net house, we had access to all of the latest tools from MS, naturally Visual Studio was in there. At around about this point in time, MS was starting to promote a tool called Team Foundation Server, this was essentially MS's take on CI. It came with all all the bells and whistles that a good CI system should offer, there was built in SCM, built in reporting, built in data collection and the ability to carry out Team Builds (MS's take on a Cruisecontrol style too). It also came with a tool called MSBUILD, which I like very much. MSBUILD was the replacement for NMake, I am going to assume that most people reading this article will be familiar with Apache Ant and/or Nant. MSBUILD borrows a lot from these tools. Essentially, it is a XML based script that allowed you to automate a great deal of pre-build, build and post-build activities. At it's simplest, it allows you to carry out a build on the command line.
Now, when it came to the CI system that I built, I didn't want to use MSBUILD, at the time it seemed to constricted for me, instead I turned to what is probably MSBUILD's biggest rival, Nant. At the present time, both these tools are pretty much identical in what they can do and how they are built and maintained, back in the day though Nant offered slightly more flexibility over MSBUILD.
Now it came down to the system that I built. One of the strong points of Nant (and MSBUILD) is that you can write your own tasks for your build/test configuration. This is great when you need to add some small things into the config - this could be something as simple as plugging in a third party tool etc. Both of these tools offer a lot of functionality from the get go, all I had to write for the first CI system there was integration with our SCM, I needed to create some Nant tasks that would work with our SCM.
When we first went live with this system, there were some complaints. These mainly came from the developers working on new build, they would now be informed of breaks very early on in the build process automatically, Cruisecontrol.Net allowed you to do this. There was some resistance to unit testing also at this time, some developers simply did not want to see their code fail at such an early stage. Both the head of development and myself held the same view - unit tests are a must have as they find issues way in advance of a build making it out into test, where an analyst may or may not find the issue. Also, the build development team was also subject to unit tests, so across the entire company unit testing became a must be done (especially when managerial start looking at lovely reports that showed them test coverage and pass rates. A lot of the developers that complained were of the "just get it to run" frame of mind. Thankfully, these developers were vastly in the majority.
As time progressed, we found that Cruisecontrol.Net was beginning to be a little constrictive for us. We were only using it for build and test for the entire company (read multiple projects) on one build server. By this time, upper management was extremely impressed with what had been achieved with the setup, it has sped up the build and test time across the board. When companies are successful, they often start branching out to get more clients to use their systems, this was no different to the one I was currently working for. It was financial software, so the money to be made from efficient development was astronomic. As the shape of the overall development changed, so did our attitude to building it changed also. With the current setup, we couldn't handle these sorts of builds on a daily basis, at this point we were running CI for one workstream only and the system would not be able to cater for different builds for different projects. We were under using the build environment we had, we only used one machine out of the four available to us. We knew we needed to change our build tools and management was concerned that we would loose development time having to migrate from one system to another. We quickly put that fear down by explaining that the build scripts we were using were not dependant on the CI system, in other words, the Nant scripts we used for all of the builds would work with any CI tool. This brought a sigh of relief to many a manager a team lead. Right up until this point, we were running a complete build and test for the new build for just one customer automatically. This would take place all the way through the day at scheduled times, this meant that developers could work away to their hearts content pretty much 24/7 (and some did come close to this).
When I first got involved with CI it was with Java development. At the start we simply used Ant to carry out our builds and tests on remote servers. As time progressed, we started to look at some of the CI build tools that were available to us. We came across Cruisecontrol, which I think was the tool de jour when it came to build servers. I was naturally impressed with the features offered by Cruisecontrol at the time. We were able to put together a simple CI environment to carry out our builds and/or churns. As time progressed, we looked for ways to integrate Cruisecontrol into our main repository - the company I was working with at the time used Perforce as it's SCM, we also had a tool called the repository that held all of our application meta data (we made mobile phone apps, so the meta data was a collection of definitions per handset and carrier). By the time I left that company, we had almost a complete integration of our build environment with our repository and SCM.
From here, I moved to a .Net software house. I brought with me the concept of Cruisecontrol and CI. My new employers could be best described as a group of energetic younger people who worked on the bleeding edge. This time round, it wasn't mobile phone apps, instead it was the ultra serious realm of financial software. When I joined this company, the guys had just put the finishing touches to a migration to .Net, easy to implement but unforseen issues cropped up - that is a story for another day ;). These guys were up for anything when it came to CI and automated testing. I introduced them to Cruisecontrol and Ant for creating a CI build environment, the head of development (my boss) at the time was very interested in implementing a unit testing regime for the newly migrated .Net code. I remember working with an intern who had been tasked with creating a set of guidelines for unit testing within the integration code, this was about the time I started looking at Cruisecontrol.Net and Nant.
Given that my new place was a .Net house, it made little sense to me to implement a suite of Java based tools when there were viable .Net versions available. With this said and done, the company branched out into the new realms of .Net CI! It was a success from the get go, the upper management liked the idea of seeing nice graphs and reports on build status, the developers like the idea of being told when a specific build passed testing - it allowed pretty much anyone in the developer and analyst pool to see what was happening with their build and others.
I feel that good CI is often based on some simple foundations. First off would have to be good code. It doesn't matter if it doesn't pass the build at a lower level, those guys should be used to new build to go through some teething problems with production code, this is something that CI would come to reduce further down the line. Next, we needed a decent environment in which to build our code. At the start, we used Crusiecontrol.Net on one builds server, but we had another three servers available to us should we need them. As unit testing was rolled out for all of development, this allowed everyone to see problems before a build made it out onto a test environment. Naturally, this annoyed some developers who didn't see the point in unit testing their code, being in the build development team I could see the importance of unit testing and so could my colleagues. The next important thing that makes up a good CI environment is Software Configuration Management. I have worked with some excellent SCM's and some truly awful (read Visual Source Safe). At this point the company was using a tool called Surround (made by Seapine). It was a fairly good SCM, a little clunky and had some performance issues, we needed to move away from it however as we needed to get to a point where we could run multiple projects from a common library of assemblies. Surround wasn't really up to this. Being a .Net house, we had access to all of the latest tools from MS, naturally Visual Studio was in there. At around about this point in time, MS was starting to promote a tool called Team Foundation Server, this was essentially MS's take on CI. It came with all all the bells and whistles that a good CI system should offer, there was built in SCM, built in reporting, built in data collection and the ability to carry out Team Builds (MS's take on a Cruisecontrol style too). It also came with a tool called MSBUILD, which I like very much. MSBUILD was the replacement for NMake, I am going to assume that most people reading this article will be familiar with Apache Ant and/or Nant. MSBUILD borrows a lot from these tools. Essentially, it is a XML based script that allowed you to automate a great deal of pre-build, build and post-build activities. At it's simplest, it allows you to carry out a build on the command line.
Now, when it came to the CI system that I built, I didn't want to use MSBUILD, at the time it seemed to constricted for me, instead I turned to what is probably MSBUILD's biggest rival, Nant. At the present time, both these tools are pretty much identical in what they can do and how they are built and maintained, back in the day though Nant offered slightly more flexibility over MSBUILD.
Now it came down to the system that I built. One of the strong points of Nant (and MSBUILD) is that you can write your own tasks for your build/test configuration. This is great when you need to add some small things into the config - this could be something as simple as plugging in a third party tool etc. Both of these tools offer a lot of functionality from the get go, all I had to write for the first CI system there was integration with our SCM, I needed to create some Nant tasks that would work with our SCM.
When we first went live with this system, there were some complaints. These mainly came from the developers working on new build, they would now be informed of breaks very early on in the build process automatically, Cruisecontrol.Net allowed you to do this. There was some resistance to unit testing also at this time, some developers simply did not want to see their code fail at such an early stage. Both the head of development and myself held the same view - unit tests are a must have as they find issues way in advance of a build making it out into test, where an analyst may or may not find the issue. Also, the build development team was also subject to unit tests, so across the entire company unit testing became a must be done (especially when managerial start looking at lovely reports that showed them test coverage and pass rates. A lot of the developers that complained were of the "just get it to run" frame of mind. Thankfully, these developers were vastly in the majority.
As time progressed, we found that Cruisecontrol.Net was beginning to be a little constrictive for us. We were only using it for build and test for the entire company (read multiple projects) on one build server. By this time, upper management was extremely impressed with what had been achieved with the setup, it has sped up the build and test time across the board. When companies are successful, they often start branching out to get more clients to use their systems, this was no different to the one I was currently working for. It was financial software, so the money to be made from efficient development was astronomic. As the shape of the overall development changed, so did our attitude to building it changed also. With the current setup, we couldn't handle these sorts of builds on a daily basis, at this point we were running CI for one workstream only and the system would not be able to cater for different builds for different projects. We were under using the build environment we had, we only used one machine out of the four available to us. We knew we needed to change our build tools and management was concerned that we would loose development time having to migrate from one system to another. We quickly put that fear down by explaining that the build scripts we were using were not dependant on the CI system, in other words, the Nant scripts we used for all of the builds would work with any CI tool. This brought a sigh of relief to many a manager a team lead. Right up until this point, we were running a complete build and test for the new build for just one customer automatically. This would take place all the way through the day at scheduled times, this meant that developers could work away to their hearts content pretty much 24/7 (and some did come close to this).
This made moving to a new CI system fairly painless, it also allowed us to see what we could do for the build, not just a test and build but hopefully a test, build, deployment and further testing. A complete lights off system that would roll back to a working build should the current code fail.
Tuesday, 3 November 2009
Building a data access layer
I recently agreed to help a student out with a software development assignment out for university. At first glance, it looks to be a pretty heavyweight peice of work for an undergrad to be given, even more so when the undergrad doesnt have a lot of experience in software development.
Essentially, the assignment is to create an Ebay-esque Windows Form app. The wording of the assignment makes it look harder than it actually is, when you get around the features that are being requested the actual technical requirement is really very simple. The assignment needs to be split into several peices, something that a lot of students probably wont be familiar with as it simply doesnt get taught at uni. The first section is the persistent data storage, I don't yet know what options are available at the moment, but the assignment spec asks for data to be retrieved from either a database or some XML. Now, I can understand why these features would be requested, it allows the application to be able to pick up its data from the local infrastructure or from a web service.
So, they key technical part here? Well, it's a data access layer. I have put together a few of these now, normally as part of an architectural migration to ease the switch over, all this assignment really needs is an appropriate DAL in order to get its data into the Windows app. It struck me that there really isnt a lot of info on how to do this rather simple thing, I think with the maturation of ORM like nHibernate and Linq-to-SQL a lot of people are over looking this for smaller projects. Anyway, I plan to put together a short howto on building your own DAL, because once you understand how the things work in the firs place, it makes implementing your own or using one of the ORM's already out there a lot more intuitive.
Essentially, the assignment is to create an Ebay-esque Windows Form app. The wording of the assignment makes it look harder than it actually is, when you get around the features that are being requested the actual technical requirement is really very simple. The assignment needs to be split into several peices, something that a lot of students probably wont be familiar with as it simply doesnt get taught at uni. The first section is the persistent data storage, I don't yet know what options are available at the moment, but the assignment spec asks for data to be retrieved from either a database or some XML. Now, I can understand why these features would be requested, it allows the application to be able to pick up its data from the local infrastructure or from a web service.
So, they key technical part here? Well, it's a data access layer. I have put together a few of these now, normally as part of an architectural migration to ease the switch over, all this assignment really needs is an appropriate DAL in order to get its data into the Windows app. It struck me that there really isnt a lot of info on how to do this rather simple thing, I think with the maturation of ORM like nHibernate and Linq-to-SQL a lot of people are over looking this for smaller projects. Anyway, I plan to put together a short howto on building your own DAL, because once you understand how the things work in the firs place, it makes implementing your own or using one of the ORM's already out there a lot more intuitive.
Sunday, 11 October 2009
Old School Computing, in its most truest sense.
Recently, I posted about the excellent machines that a rejuvinated Acorn Computers are now selling on the Internet. It got me thinking, anyone who went through an English school suring the late 80's and early 90's should have at least some distant memory of these rather fine machines.
For those that don't know, Acorn was one of the UK's only computer builders, a lot of people wont even remember them these days, but the ones who do will no doubt have fond memories of the BBC Master and probably playing Chuckie Egg on it.
Acorn made computers from 1978 to 1998, when they finally succumbed to the dominance of the PC architeture. There is loads about them on Wikipedia: http://en.wikipedia.org/wiki/Acorn_Computers, there are loads of these machines about now, mainly because of the sheer amount that were installed in schools across the country for so long. The first ever computer I owned was an Acorn Electron back in the early 80's. My parents thought that it might improve my hand/eye coordination to play games on it!! I think what many people wont realise is the lasting and prominent impact Acorn Computers have had on our everyday lives. Not only did they build their own computers, but they made their own OS, architecture and hardware. Acorn are resposible for developing the ARM processor, a peice of hardware that pretty much everyone carries around in their pocket, powering their mobile phone. It would be a fair bet to make that there is also one in your set top box at home, powering Sky, Virgin Media or your freeview/sat tuner. It doesnt start and end there either, ARM processors powered another venerable computing device towards the end of the 90's, the PSION Series 5. This is a very notable device as it was the precursor to the S60 mobile phone platform, the OS that powered it was called EPOC and it pretty much turned into Symbian - now things should start to be recogniseable!
With that said, I have now in front of me an original Acorn A7000+ desktop computer from a school down in England. It should run, I have powered it on and got the desktop up and displayed on my monitor. I plan to rennovate this UK computing relic to get it back up and running properly. I remember schools were using these machines right up until 2001 in some parts of the UK, this one I have here is a clear indication as it comes with an all important ethernet adapter.
One of the notable things about these machines is that they don't really need hard drives, the entire OS and all its supporting applications are stored on ROM. When you want to upgrade the OS, you simply replace the ROMs with your new set. This isn't something we see at all these days in a desktop computer, unless you are running a setup with embedded Linux.
I recall from the last time I saw an Acorn machine in operation, that it had a fully functional web browser. So, my plan right now is to get this bad boy up and running and connected to the Internet so that I can try and do some simple things like email and facebook. The example I have here, an A7000+, has a hard drive installed, as well as a CD writer, so this means I will be able to install software to it if I need to. From what I can see from the boot up screen, this machine is running RISC OS 3.7. From what I can remember, this was the last main release of the OS prior to Acorns demise, however since then there have been three seperate releases of newer OS's. In a rather different move to the normal distributions of Windows and Linux etc that we see now, a new company was formed in 1999 to release RISC OS 4. Not long after this, a seperate company release a RISC OS 5 for a seperate line of devices, but as far as I can tell this version of the OS is only for machines made by a company called Castle. This confuses me a bit, as far as I can tell this version of the OS has never really been available seperately.
But, a further twist is this, a new OS has been recently released, RISC OS 6... I have no idea how much of a departure this will be from the RISC OS I know and love. One thing that is very notable about RISC OS is that it pretty much introduced the concept of the task bar (as far as I know). This is very familiar to Apple users and now, to Windows 7 users, its a feature that Acorn introduced in 1988 though... As soon as I get this one up and running, I will start to get some screen shots up and running.
For those that don't know, Acorn was one of the UK's only computer builders, a lot of people wont even remember them these days, but the ones who do will no doubt have fond memories of the BBC Master and probably playing Chuckie Egg on it.
Acorn made computers from 1978 to 1998, when they finally succumbed to the dominance of the PC architeture. There is loads about them on Wikipedia: http://en.wikipedia.org/wiki/Acorn_Computers, there are loads of these machines about now, mainly because of the sheer amount that were installed in schools across the country for so long. The first ever computer I owned was an Acorn Electron back in the early 80's. My parents thought that it might improve my hand/eye coordination to play games on it!! I think what many people wont realise is the lasting and prominent impact Acorn Computers have had on our everyday lives. Not only did they build their own computers, but they made their own OS, architecture and hardware. Acorn are resposible for developing the ARM processor, a peice of hardware that pretty much everyone carries around in their pocket, powering their mobile phone. It would be a fair bet to make that there is also one in your set top box at home, powering Sky, Virgin Media or your freeview/sat tuner. It doesnt start and end there either, ARM processors powered another venerable computing device towards the end of the 90's, the PSION Series 5. This is a very notable device as it was the precursor to the S60 mobile phone platform, the OS that powered it was called EPOC and it pretty much turned into Symbian - now things should start to be recogniseable!
With that said, I have now in front of me an original Acorn A7000+ desktop computer from a school down in England. It should run, I have powered it on and got the desktop up and displayed on my monitor. I plan to rennovate this UK computing relic to get it back up and running properly. I remember schools were using these machines right up until 2001 in some parts of the UK, this one I have here is a clear indication as it comes with an all important ethernet adapter.
One of the notable things about these machines is that they don't really need hard drives, the entire OS and all its supporting applications are stored on ROM. When you want to upgrade the OS, you simply replace the ROMs with your new set. This isn't something we see at all these days in a desktop computer, unless you are running a setup with embedded Linux.
I recall from the last time I saw an Acorn machine in operation, that it had a fully functional web browser. So, my plan right now is to get this bad boy up and running and connected to the Internet so that I can try and do some simple things like email and facebook. The example I have here, an A7000+, has a hard drive installed, as well as a CD writer, so this means I will be able to install software to it if I need to. From what I can see from the boot up screen, this machine is running RISC OS 3.7. From what I can remember, this was the last main release of the OS prior to Acorns demise, however since then there have been three seperate releases of newer OS's. In a rather different move to the normal distributions of Windows and Linux etc that we see now, a new company was formed in 1999 to release RISC OS 4. Not long after this, a seperate company release a RISC OS 5 for a seperate line of devices, but as far as I can tell this version of the OS is only for machines made by a company called Castle. This confuses me a bit, as far as I can tell this version of the OS has never really been available seperately.
But, a further twist is this, a new OS has been recently released, RISC OS 6... I have no idea how much of a departure this will be from the RISC OS I know and love. One thing that is very notable about RISC OS is that it pretty much introduced the concept of the task bar (as far as I know). This is very familiar to Apple users and now, to Windows 7 users, its a feature that Acorn introduced in 1988 though... As soon as I get this one up and running, I will start to get some screen shots up and running.
Friday, 7 August 2009
Sorting Lists with Comparison in .Net
The other day, I made a post about invoking methods using reflection. One of the things I wanted to do in my code was get a list of the methods in a class and then run them. However, what I didnt mention was that I wanted the methods added to my list in an order. Sorting a list is easy if you are working with a list of strings or numbers. But the list I generated was a list of type MethodInfo - something that .Sort wouldnt work with.
So, to overcome this, I did the following:
And out pops a sorted list of type MethodInfo. Short, but sweet and also provides a nice little example of how lists of different types can be sorted.
So, to overcome this, I did the following:
sectionNames.Sort(delegate(MethodInfo m1, MethodInfo m2) { return m1.Name.CompareTo(m2.Name); });
And out pops a sorted list of type MethodInfo. Short, but sweet and also provides a nice little example of how lists of different types can be sorted.
Friday, 31 July 2009
Sick of my phone
I am totally sick of my phone just now. For the past five years I have been using Nokia phones, mainly S60 smartphones. However, over the last few years I have been getting more and more frustrated with the S60 OS. It sees to me that once Nokia gained control of Symbian (at least I think it did) things started getting bad.
At the present time, I use an N96 - when it wants to work. Recently, one of my friends at work got hold of the HTC Hero, a smartphone that uses Google's Android 1.5. As far as I am concerened, it out cools the iPhone. However, I dont know if I want to get another smartphone. Right now I am thinking about getting a normal phone and some form of Internet Tablet/PDA - ironically I am looking at getting a Nokia N810. My reasons for this? Well, out of the box it runs a Linux, but you can also install Android on it as well :).
At the present time, I use an N96 - when it wants to work. Recently, one of my friends at work got hold of the HTC Hero, a smartphone that uses Google's Android 1.5. As far as I am concerened, it out cools the iPhone. However, I dont know if I want to get another smartphone. Right now I am thinking about getting a normal phone and some form of Internet Tablet/PDA - ironically I am looking at getting a Nokia N810. My reasons for this? Well, out of the box it runs a Linux, but you can also install Android on it as well :).
PDF Generation with PDFJet
As mentioned previously, I have been working a lot on report generation. Where I work just now, we produce a lot of reports. A lot of them are produced manually and are very large. An ideal candidate for automation.
I need to produce them in a number of different formats, pdf is the first one I tackled. All of the reports I need to produce use tables, so I needed to find a .Net pdf library that had this functionality. I took a look at what was on offer, open source, closed source and commercial. I went for a lib called PDFJet. This is a fairly mature Java pdf library that has been ported over to .Net for C# http://www.pdfjet.com/. Its fairly cheap and whilst it lacks a lot of in depth examples, there are quite a few available on their website. The support is really good too - if you have a question, the guys are able to provide feedback very quickly.
It is very well featured, but I am basically using it to generate tables from datatables. I have been using it in earnest for about a week now, so I will try and post some examples of how it can be used here. There are two ways of creating a table with PDFJet, you can use a delimited text file holding the data you need or you can build a table programatically. Doing it in the code is quite tricky, to do this you need to build a list of lists of type cell - not as easy as it sounds... However, I am very impressed with this library and the things it can do.
I need to produce them in a number of different formats, pdf is the first one I tackled. All of the reports I need to produce use tables, so I needed to find a .Net pdf library that had this functionality. I took a look at what was on offer, open source, closed source and commercial. I went for a lib called PDFJet. This is a fairly mature Java pdf library that has been ported over to .Net for C# http://www.pdfjet.com/. Its fairly cheap and whilst it lacks a lot of in depth examples, there are quite a few available on their website. The support is really good too - if you have a question, the guys are able to provide feedback very quickly.
It is very well featured, but I am basically using it to generate tables from datatables. I have been using it in earnest for about a week now, so I will try and post some examples of how it can be used here. There are two ways of creating a table with PDFJet, you can use a delimited text file holding the data you need or you can build a table programatically. Doing it in the code is quite tricky, to do this you need to build a list of lists of type cell - not as easy as it sounds... However, I am very impressed with this library and the things it can do.
Subscribe to:
Posts (Atom)