જૂનો WinINet પ્રોક્સી સહાયક 64-બિટ બિલ્ડમાં કેમ તૂટે છે
C# પ્રોક્સી interop ઉદાહરણોમાં પોઇન્ટર કાપણી ઓળખો અને ફરી વાપરતા પહેલાં સ્ટ્રક્ચર લેઆઉટ અને મેમરી માલિકીની સમીક્ષા કરો.
એક કાસ્ટ દેખીતી રીતે સામાન્ય પ્રોક્સી સેટિંગ્સ સહાયકને આર્કિટેક્ચર-આધારિત નિષ્ફળતામાં ફેરવી શકે છે:
current = (IntPtr)((int)current + optionSize);
તે કોડ આગલા સ્ટ્રક્ચરનું કદ ઉમેરતા પહેલાં મૂળ સરનામાને 32-બિટ પૂર્ણાંકમાં સંકુચિત કરે છે. 64-બિટ પ્રક્રિયા એવા સરનામાં રાખી શકે છે જે બંધ બેસતા નથી. રૂપાંતરણ અને મૂલ્ય પર આધાર રાખીને પરિણામ ઓવરફ્લો અપવાદ અથવા અમાન્ય સરનામું હોઈ શકે છે. બિલ્ડને x86 પર પાછું ફેરવવાથી ભૂલ છુપાઈ શકે છે, પરંતુ તે interop અમલીકરણને તે વર્કઅરાઉન્ડ પર આધારિત રાખે છે.
સરનામાંને પોઇન્ટર-કદ સ્વરૂપમાં રાખો. ઉદાહરણ તરીકે, પહેલેથી ફાળવેલ એરેમાંથી આગળ વધવા માટે આ વાપરી શકાય:
IntPtr item = IntPtr.Add(buffer, checked(index * optionSize));
ઓફસેટ પૂર્ણાંક રહે છે; સરનામું પોતે એકમાંથી દબાવવામાં આવતું નથી. ફાળવણીનું કદ અને ઇન્ડેક્સ હજી પણ માન્ય હોવા જોઈએ.
પછી આસપાસની ઘોષણાઓની તપાસ કરો
WinINet ના પ્રતિ-કનેક્શન વિકલ્પોમાં એક યુનિયન છે જેના સભ્યોમાં DWORD, સ્ટ્રિંગ પોઇન્ટર અને FILETIMEનો સમાવેશ થાય છે. પોઇન્ટર ફીલ્ડને IntPtr જોઈએ; DWORD ફીલ્ડ 32-બિટ રહે છે. મૂળ સંરેખણ મહત્વપૂર્ણ છે, તેથી દરેક પૂર્ણાંકને 64-બિટ પૂર્ણાંકથી બદલવો અથવા પેક કરેલ લેઆઉટ ફરજિયાત કરવો એ યોગ્ય સમારકામ નથી.
એરેમાંથી પસાર થતી વખતે marshaling પછીના સ્ટ્રક્ચર કદનો ઉપયોગ કરો, ANSI અથવા Unicode ઘોષણાને સુસંગત રીતે મેળવો અને દરેક ફાળવણીને અલગથી ટ્રેક કરો. વિકલ્પ સ્ટ્રક્ચરનો બ્લોક મુક્ત કરવાથી અન્યત્ર ફાળવેલા અને તે સ્ટ્રક્ચર દ્વારા સંદર્ભિત સ્ટ્રિંગ આપમેળે મુક્ત થતા નથી.
છેવટે, સેટિંગ્સ અવકાશનો પ્રશ્ન મેમરી શુદ્ધતાથી અલગ રાખો. કાસ્ટ સુધારવાથી સાબિત થતું નથી કે સહાયકનો પસંદ કરેલો WinINet વિકલ્પ ફક્ત એક નિયંત્રણ, એક પ્રક્રિયા અથવા વર્તમાન વપરાશકર્તાની સેટિંગ્સને જ અસર કરે છે. જૂના નમૂનાનો બાકીનો ભાગ સ્વીકારતા પહેલાં તે API વર્તન ચકાસો. જો તે રિફ્રેશ સૂચનાઓ પણ મોકલે છે, ઇચ્છિત અવકાશ માટે તેમને પસંદ કરો.