Release is what we build for final released binaries. By default we produce unsigned binaries unless the strong name key is present. If you rename "MSSharedLibDelaySigned.snk" to "MSSharedLibKey.snk" then you will produce delay signed binaries w/ the same key that we use. You unfortunately cannot produce really signed binaries because it requires submitting the binaries to a service inside of Microsoft which signs them w/ the real key. You can disable verification of the assemblies with "sn -Vr *,31bf3856ad364e35" (or individually like sn -Vr IronPython,31bf3856ad364e35 which is the more secure thing to do). Or you can just use the unsigned ones which might be all around easier.
From: users-boun...@lists.ironpython.com [mailto:users-boun...@lists.ironpython.com] On Behalf Of Idan Zaltzberg Sent: Tuesday, October 05, 2010 2:46 AM To: Discussion of IronPython Subject: Re: [IronPython] Possible bug in Ipy 2.6.1 WeakDictionary I want to try to build from source. We are using the 2.6.1 release from April on .Net 2.0, so I guess I need to download: IronPython-2.6.1-Src-Net20SP1.zip After that, can you tell which configuration to use in Visual Studio in order to get the same result as d/ling the binaries directly from site? From: users-boun...@lists.ironpython.com<mailto:users-boun...@lists.ironpython.com> [mailto:users-boun...@lists.ironpython.com<mailto:users-boun...@lists.ironpython.com>] On Behalf Of Dino Viehland Sent: Monday, October 04, 2010 7:22 PM To: Discussion of IronPython Subject: Re: [IronPython] Possible bug in Ipy 2.6.1 WeakDictionary Nope, you have it right - this is fixed in the Main branch and internally it's fixed in the 2.6 branch as well (There was a report about this from some internal uses of IronPython). Unfortunately it looks like the fix hasn't propagated out to the 2.6 branch on CodePlex for some reason. I'll try and figure out what's going on there but either way it'll be fixed in the next set of releases. If you want to build from source you can just add a call to CheckCleanup(); in there before the dict[new WeakObject(...)] = ... assignment. From: users-boun...@lists.ironpython.com<mailto:users-boun...@lists.ironpython.com> [mailto:users-boun...@lists.ironpython.com<mailto:users-boun...@lists.ironpython.com>] On Behalf Of Idan Zaltzberg Sent: Monday, October 04, 2010 9:02 AM To: Discussion of IronPython Subject: [IronPython] Possible bug in Ipy 2.6.1 WeakDictionary Hi, I'm investigating memory leakage in a Ipy 2.6.1 application. Using WinDbg I found a WeakDictionary that is only increasing in size, though most of the instances are already collected. This WeakDicitionary is used by a DelegationInfo object. Looking at the code, I think I found the problem: The method CheckCleanup is called the method "public void Add(TKey key, TValue value)" But it NOT called from the indexer: public TValue this[TKey key] { get { return dict[key]; } set { // If the WeakHash already holds this value as a key, it will lead to a circular-reference and result // in the objects being kept alive forever. The caller needs to ensure that this cannot happen. Debug.Assert(!dict.ContainsKey(value)); dict[new WeakObject(key)] = value; } } Since the dictionary is populated using the indexer in DelegateInfo: _constantMap[target] = new WeakReference(clone = (object[])_constants.Clone()); This means that the "version" field is never updated, and the dictionary never gets cleaned up. Have I got something wrong here? Thanks
_______________________________________________ Users mailing list Users@lists.ironpython.com http://lists.ironpython.com/listinfo.cgi/users-ironpython.com
