Friday, May 07, 2010

POS for .NET and Framework 4

Sigh. It would *appear* that the Microsoft Pos .Net library and the .Net 4.0 framework are not 100% compatible. This Pos .Net Forum post explains the problem, which is basically that the Pos .Net binaries include CAS policies (which they should have in previous versions) and .Net 4 has dropped CAS support in many cases. As a result .Net 4 now generates a warning/error unless the application configuration file is modified to specifically re-enable CAS.

Hopefully Microsoft will provide a fix for Pos .Net soon... but perhaps more of a concern is what other libraries, be they 1st, 2nd or 3rd party, are now broken ? You're own libraries you can update easily enough (probably), but if this becomes a prevalent problem with other .Net dependencies it could be a real headache !

9 comments:

  1. I would like to get your expert opinion on what will be best option(use POS for .Net or some other ) to intercept the data send the text data to a POS Printer and send to my own application. I would also like this to work with OPOS devices too.

    Thanks in advance

    ReplyDelete
  2. Hi,

    If you want to work with OPOS devices at all, and you are in .Net, I would defintely use Pos .Net. If you find a reason not to (and I can't think of one) then I'd use OPOS directly, but my preference would be to use Pos .Net and I see no reason why you shouldn't from your description.

    I'm not sure where you want to intercept data (between what and what ?) so I don't know if Pos .Net will help you with that, but it should work with the printing.

    ReplyDelete
  3. I appreciate the quick response. What I would like to do is get data send to the printer to my own application(BI app that can be used by retailers to give instant offers). What would be your suggestion to setting up a dummy printer and try to get that data for testing using POS.Net.

    Thanks

    ReplyDelete
  4. If I understand you correctly, you'd like to intercept data going to the printer in your own application ?

    The only way I can think of to do that with Pos .Net would be to write your own service object, but it would have to pass all calls on to another service object to allow the printing to happen. That would be a reasonable amount of work, and I don't know how hard it would be in detail.

    I'd suggest that intercepting the printer data is probably the wrong thing to do anyway. Receipts are in different formats, contain formatting info as well as business data and may not have all the information that would be useful to you. If you can, I'd try to get the data from it's source, either from the POS (in it's own database, or via services or someting), or from the back office system it sends data to.

    If you do try to intercept data as it goes to the printer, you'll need to have both a Pos .Net solution, an OPOS soluton, a JPOS solution and a Windows Printer driver solution to get good coverage across many POS'. You *might* be able to get by with just a Windows and OPOS solution, but I'm not 100% sure on that.

    Good luck.

    ReplyDelete
  5. I think Microsoft is loosing out and if developers do not wake up they might as well be left out in the emerging world of technologies. Just a matter of interest I had to revert to .NetFramework 2.0 from 4 because of POS.Net incompatibility. After 15 years of my life as adeveloper on microsoft platform am considering leaving probably to JAVA Platform.

    ReplyDelete
  6. Hi,

    I am creating a service object to intercept the printed receipt and send the receipt information to my system. I've created a "POS For .NET" service object and it is working fine. Do I have to do a legacy COM OPOS to cover legacy POS application? if yes. do you know any website, document or any resource that can help me in creating this service object.

    Thanks

    ReplyDelete
    Replies
    1. Hi,

      It's been so long since I worked with OPOS I can't remember the rules sorry. I *think* your .NET service object should work fine with OPOS if you mark it as a COM registerable assembly (in the project properties) and build it, then register it on the client machines when it's deployed. I'm can't recall if OPOS required anything else to register/install a service object.

      If you search for UPOS specification with Google, you should find good info on the spec that OPOS is an implementation of, and probably links to the OPOS specific detail too.

      Good luck !

      Delete
  7. Hi, I have a similar case, I posted a question on stackoverlow,
    http://stackoverflow.com/q/15632453/2210713

    I'm looking for code example, I looked in the internet everywhere for such with no luck, can you please try to help me?

    regards

    ReplyDelete
  8. Hi,

    I'm afraid I don't have a sample for what you are trying to do, sorry. I haven't worked with OPOS since the 90's and was never that familiar with it in detail.I don't have any service object code handy to test with etc. I'm also personally very busy, at home and at work so I don't really have time right now to try crafting a custom solution for this and figuring out all the details.

    Perhaps you could work with the other poster who had a similar question and between you an answer might be found ?

    To answer the questions in your post as best I can;

    1. I *think* it is possible to use a POS .Net service object in OPOS, but I am not sure. I think the two requirements are for the POS .Net service object/assembly to be marked as a COM component, and then "correctly deployed" on the target machines. I can't recall the deployment details - I assume the assembly must be COM registered and I think the assembly file may have to be in a particular folder but I cannot recall. The OPOS documentation for installing a normal OPOS equivalent should tell you. It may be this still doesn't work - there may be a requirement to implement specific COM interfaces for the integration to succeed. IF that is the case, I'm not sure if you can use C# attributes to indicate you support the correct COM interface id's, or if a wholly new service object is required.

    2. If you need to build an OPOS specific object then your best bet is probably C or C++, but it may be possible with C# if you implement the appropriate interfaces etc. I am not sure.

    3. I'm inclined to think not, but who am I to say ? Why are you trying to capture the receipts ? Usually when I've heard of this being done it's been in the context of trying to grab the item or payment information to do loyalty/rewards/analysis. If that's the case then I personally think the approach is wrong. Even if you could capture the receipt data for any OPOS/POS .Net POS you still can't capture the others that print directly to hardware or via Windows Print drivers. Even if you can capture all of those, you still have to parse the receipt which is designed to be human readable not machine readable. Finally, the receipt formats may be different on each POS and some receipt formats may not even contain enough detail to do what you need. If it were me, I would be trying to integrate to each POS or the backend (depending on requirements), using a common interface if possible (do the POS' all use the ARTs file format for the sales ? Can you read the export files/intercept the service calls ?).

    If however, none of those things are true for your use case and intercepting the receipts works for you, then you should keep doing that.

    Also, you could try posting in the Microsoft POS .Net forum - there are a lot of knowledgeable people there and they may be able to help you out.

    Best of luck !
    Yort

    ReplyDelete