Aaron,

Your other option may be to keep your application as client/server using .NET WinForms, WebServices and back-end data and application servers. This gives you a nicer, rich-client UI, but still allows you to access your data remotely. Seems to be the best of both worlds. <g> Installation on the client-side won't be as easy as it would be for ASP.NET (which wouldn't require any additional client-side stuff), but there are ways to auto-deploy WinForm applications which simplify the process to some degree. You'd then be able to do COM Port stuff (although don't ask me how, I don't have a clue which API's you might need to do this ... but the point is that it *would* be do-able).

~~Bonnie

>Sorry, I didn't explain myself correctly. I didn't mean we were moving from ASP to ASP.NET, rather we are moving from a conventional VFP / SQL Server application to ASP.NET. We have many reasons to do this, but one minor reason is that it will allow us to host the data in a single location which will ease installation, configuration and support - rather than having separate SQL Servers and VFP applications installed locally in different countries.
>
>That is the target but we have to retain hardware device comms at the client. There is always something that gets in the way <g>.
>
>Regards,
>
>Aaron
>
>>I'm not sure I'm following you. What difference does ASP vs. ASP.Net make? >This is a client side issue that is independent of server software used...
>
>+++ Rick ---
>
>>>Thanks Rick for the response.
>>>
>>>Sadly this is what I feared. One of the reasons we are switching to ASP is to reduce installation problems as we will have 5k+ clients. I guess we are going to have to try and find the best "bad" solution we can come up with.
>>>
>>>Anyway, it was worth a shot in the dark.
>>>
>>>Thanks again.
>>>
>>>Aaron