>>After more thinking about this, I think it is normal we are not allowed to assigned a NameObjectCollectionBase object to another one as its main root would differ at first making sense for the error message I am getting at the designer level. It might work for a dictionary but not for a NameObjectCollectionBase object.
>>
>>I will have to try with the locking mechanism instead.
>>
>>In the meantime, if you see a workaround with the 2nd approach or if you would know why I am getting this, feel free to let me know.
>
>NameObjectCollectionBase or dictionary - the class is does not matter
>
>
>I've used the volatile keyword http://msdn.microsoft.com/en-us/library/x13ttww7.aspx
>See also here http://www.yoda.arachsys.com/csharp/threads/volatility.shtml
>
>
>

>	public class AClass
>	{
>		private volatile Dictionary<string, string> Tables_;
>	
>		public Dictionary<string, string> Tables
>		{
>			get; private set; 
>
>		}
>
>		public AClass()
>		{
>			// Initialize Tables
>			Tables_ = new Dictionary<string, string>();
>			Tables_.Add("1", "one");
>			Tables_.Add("2", "two");
>		}
>		public void ReInitializeTables()
>		{
>			// do not set to null
>
>			Dictionary<string, string> tmp = new Dictionary<string, string>();
>			tmp.Add("3", "three");
>			tmp.Add("4", "four");
>
>			Tables_ = tmp;  // assign new initialized object
>
>		}
>	}

IIRC, VB doesn't have 'volatile' - maybe Monitor class ?

But, still not understanding enough about Michel's system, I'm not sure locking at this level will resolve the issue. True - it will guarantee that the hit does not receive an inconsistent or out of date version of the data on entry. But it does not prevent the reverse - data being changed on another thread before the hit exits. The only way to do that would be to hold a lock on the 'hit' thread until it completed - obviously not practical for a IIS site ?