Windows 7 ships with .NET 4 I believe, so it should definitely work. Hmmm... looks like it didn't ship by default but was a required update so any Win7 machine that is updated should work.

http://superuser.com/questions/298025/does-windows-7-have-net-4-installed-by-default

The other issue maybe network loading of assemblies:

http://west-wind.com/webconnection/docs/_36e0qlogr.htm

There are a few other topics related to startup and loading in that same help branch.

As to Newtonsoft.json - you need to include that assembly somewhere in the FoxPro path - that's what's used for the JSON deserialization. It's an open source third party library that's become the defacto .NET JSON library and is distributed by Microsoft with most major products (but locally - not globally so it requires copying of the DLL).

For a little background: As much as this seems like overkill to use .NET, JSON parsing using only FoxPro (and maybe some C code) is very difficult because of FoxPro's inability to efficiently walk strings character by character, so some external mechanism is needed to extract the data efficiently. For a lot of things the FoxPro parsers may work just fine - you can try wwJsonSerializer.Deserialize() as would Craig's probably. But there are things that don't work and parsing large documents can be very slow.
My old JSON parser was limited. Craig's parser is actually better but it too becomes slow and has some failures with heavily nested objects and arrays. I also built a .NET parser a long while back, but it too had a number of deficiencies that would fail. So rather than introduce more imperfect parsing, I chose to rely on a proven third party parser to do the parsing the right way :-) Building reliable language serializers is a full time job and one that's better left to people very famiilar with parser logic.


+++ Rick ---

>On Win7 stations the call to dotnetbridge always fails with an error that cannot access the .Net, so I figured it needed a higher level of .Net than is installed, and I cannot get permission from the client for that. I see a V2 option in the .prg I am going to try that.
>
>
>>>It seems I have to have .Net installed to use the deserializer, correct? That is a deal killer.
>>
>>DeserializeJson() requires .NET yes. It's the most reliable way though as it uses a full JSON parser to parse the JSON. There's also Deserialize() which uses FoxPro code but is not as reliable - especially with arrays, but you can give it a try. It looks like the issue though isn't with the JSON parser (so json.prg probably works) but with the actual HTTP call.
>>
>>> deal killer
>>
>>Why? Post XP all machines have .NET 2.0 installed and I bet even XP machines today have .NET 2.0 installed as so many apps use it.
>>
>>+++ Rick ---
>>
>>>
>>>I have other deserializing code, but the issue is when the jSon is really a set of records rather than just a long string.
>>>
>>>>Almost certainly the issue is either a cookie or authentication that is happening when you go to the site with the browser but not with your foxpro HTTP client code. XmlHttp uses the WinInet stack so it shares cookies between sessions that's why ti works once you log in with a browser.
>>>>
>>>>Uhm you say you get a 200 response but you get Internal Server Error (which is a 500.x error)? How are you getting both?
>>>>
>>>>The best thing to do is trace the browser session. Use fiddler (http://telerik.com/fiddler) and then clear all your cookies first. Then go to the site and see what you capture with Fiddler. But try to hit the page with the browser directly rather than through other links first. Many sites use internal redirection with cookie assignments in those redirects to enforce 'live' users.
>>>>
>>>>Finally - XMLHTTP is a pain to work with and it doesn't do very well for more advanced HTTP concepts. If you have security or extra redirects, or binary data etc. it doesn't work very well.
>>>>
>>>>Since I know you use West Wind stuff already it might be much easier to:
>>>>
>>>>

>>>>DO wwHttp
>>>>do wwJsonSerializer
>>>>loHttp = CREATEOBJECT("wwHttp")
>>>>lcJson = loHttp.HttpGet(lcUrl)
>>>>IF (loHttp.nError # 0)
>>>>   ? loHttp.cErrorMsg
>>>>   RETURN
>>>>ENDIF
>>>>
>>>>loSer = CREATEOBJECT("wwJsonSerializer")
>>>>loResult = loSer.DeserializeJson(lcJson)
>>>>
>>>>? loResult.Value
>>>>...
>>>>

>>>>
>>>>+++ Rick ---
>>>>
>>>>
>>>>>I have an application that verifies data by calling an HTML page from a third party, and that HTML page returns a JSON string which I parse.
>>>>>
>>>>>I have had the IT folks open the firewall to access the site, let's call it THESITE.HTML.
>>>>>
>>>>>Then I do this:
>>>>>

>>>>>local oxml ,   oAuto, oJson, lcJson
>>>>>lcKey =   ...(whole bunch of code I cannot show that creates the string to be passed)
>>>>>lcOpen = ...(URL I cannot show you)
>>>>>oXml = CREATEOBJECT("Microsoft.XMLHTTP")
>>>>>oXml.OPEN( "POST", lcOpen, .F.)			&& false sets to synchronous, returns only after call completes
>>>>>oXml.SEND()
>>>>>
>>>>>IF oXML.statustext <> "OK" 
>>>>>	=MESSAGEBOX("Cannot process "+CHR(13)+"Error: "+oxml.statustext,16,"VIN")
>>>>>	RETURN
>>>>>ENDIF
>>>>>IF "SERVER_ERROR" $ oxml.responsetext
>>>>> . . .some error code
>>>>>ENDIF
>>>>>
>>>>>oJson=NEWOBJECT("json","json.prg")
>>>>>* have to fix a couple things the parses does not like, although perfectly valid
>>>>>* json
>>>>>* #1, using [] for empty values
>>>>>lcJson = oxml.responsetext
>>>>>lcJson = STRTRAN(lcJson, "[]", '""')
>>>>>* #2 our parses does not like the [ or ] characters, also valid but not needed
>>>>>lcJson = STRTRAN(lcJson, "[", "")
>>>>>lcJson = STRTRAN(lcJson, "]", "")
>>>>>
>>>>>oAuto=oJson.parse(lcJson)
>>>>>
>>>>>&& . . . update some values
>>>>>
>>>>>thisform.Refresh
>>>>>
>>>>>

>>>>>
>>>>>Now the problem: I always receive an OK 200 connect but get an internal server error message from the web site, UNLESS I have opened a browser and previously gone to the SAME exact URL with the SAME exact string. Once I have done that, I could close the browser and my code works fine. But since there are about 1000 lookups a day, that is not a great plan <s>.
>>>>>
>>>>>XMLHttp is supposed to work with the machines WINET stack and use the same HTTP call as a browser, but something is off here.
>>>>>
>>>>>What am I missing?
>>>>>
>>>>>TIA