InfoPath Dev

Hello everyone I saw this forum and thought I might give it a shot, from what I know there hasn't been a fix from the form side for this, I saw there was this thread:

http://www.infopathdev.com/forums/p/12529/44100.aspx which explains how an end-user can fix the problem.  However I'm in a situation where there may be a lot of people using my form and I don't want to have each end-user who happens to have installed their office before .net 2.0 to get this error. 

So in a nutshell my question is:  Is there any kind of change I can make on the form to get around this issue so I can fix that error on my form for all users rather than having each end-user who has this particular problem have to go and fix that (they don't all have admin rights to their computer either so it's not even as simple as them just changing it). 

I created the form in InfoPath 2010 but saved it as a 2007 form template so those with older versions of InfoPath could still use it.  My form does have a bit of custom code in it, but it's nothing that would require full trust, I essentially just use the code to process data from a SharePoint list.  And a few other handy things.

 It has data connections to submit to a SharePoint form library, it has the GetUserProfileByName data connection explained here if you're not familiar with it:

http://blogs.microsoft.co.il/blogs/itaysk/archive/2007/04/05/InfoPath-_2D00_-Get-the-current-user-without-writing-code.aspx 

and it has a couple data connections that get data from a SharePoint list

 Thanks in advance for taking the time to read this!

Unfortunately, if your form has .NET code in it, and your users are opening it with the InfoPath client, and they don't have .NET programability support installed, it is a per machine fix. Do you have InfoPath Forms Services set up? What about publishing this as a browser form? Then they don't have to modify their machines.

Otherwise, I'd look into ways to remove the code...

Thanks for replying, it's not a browser form; I think I tried that at some point and it spat out some compatability issues at me that I didn't want to deal with.  As far as the code goes I'm using a SharePoint list as a mapping table so users can conveniently modify how the form acts without having access to actually change anything on the form.  The main purpose of my code is basically just reading all of the items on the list and filtering through all the data in the columns, I couldn't find any way to do this without code or I would have done that in the first place probably.  Anyway as it turns out not very many people seem to be getting this error, initially it was happening a lot but it seems to be uncommon enough that it's probably fine if it's just a per machine fix...

Anyways thanks again for the reply!