I don't get it, do you want to debug a dll without an executable?

//daniel

So, how do you know its failing? Do you attempt to read it once set or?

//daniel

Do you see any error messages?

//daniel

My guess is that he refers to the TreeviewItemViewModels he adds to this.Items. That said, I still do not understand what he actually means with they being in memory. They will be garbage collected by the GC when no more references exists and when a the GC is triggered.

Could you provide some more detailed information about how you use this from C#? Could you also provide more details about what kind of error you see when trying to use the dll? If my COM-memory is not totally wrong, CoCreateInstance() cannot be called until the calling thread has called CoInitalize(). Could that be your problem?

//daniel

To be able to unload dll's you need to load them into a separate ApplicationDomain and when you are done with the dll you need to unload the AppDomain.

//daniel

Ok, good. Please do think about this though. As I tried to point out (and others with me), this might not be a good solution even if it is doable. Thinking a bit ahead I do see problems wth deployment and that this creates an unattractive dependency between projects.

//daniel

I am still not sure this is what you really want to do, but this might get you started:

static void Main(string[] args)
{
//
// Read your "local" App.config file
//
string localValue = ConfigurationManager.AppSettings["Akey"];
Console.WriteLine("Local Value: " + localValue);

     //
     // Read a "remote", i.e. a different App.config file.
     //
     Configuration c = ConfigurationManager.OpenMappedExeConfiguration(
       new ExeConfigurationFileMap() { ExeConfigFilename = @"C:\\temp\\App.config"},
       ConfigurationUserLevel.None);
     
     string remoteValue = c.AppSettings.Settings\["AKey"\].Value;
     Console.WriteLine("Remote value: " + remoteValue);

     Console.ReadLine();
  }

This will read your App.config file residing in c:\temp. The app.config file I used looks as:

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<appSettings>
<add key="AKey" value="YaddaYaddaYoo"/>
</appSettings>
</configuration>

How do you intend to deploy these projects? You could open that file on your build machine, but that will most likely not work after deployment. Can you specify a bit more about you actually want to achieve?

//daniel

Will you still not have problems when the day number is less than 13? 04/05/11 and 05/04/11 will probably be ok with several cultures?

//daniel

modified on Tuesday, September 13, 2011 5:06 AM

Since you are adding Emp{Empname="nitin", ID=1} twice I guess finding it twice in your foreach shouldn't be that much of a surprise. I would use intersect. That means implementing IEquatable for your class (and perhaps GetHashCode). Like this:

class Emp : IEquatable<Emp>
{
public string Empname { get; set; }
public int ID { get; set; }

#region IEquatable<Emp> Members

public bool Equals(Emp other)
{
if (Object.ReferenceEquals(other, null)) return false;
if (Object.ReferenceEquals(other, this)) return true;

  return ID == other.ID && 
               Empname.Equals(other.Empname);

}

#endregion

public override int GetHashCode()
{
//Calculate hash
return Empname == null ? 0 : Empname.GetHashCode()^
ID.GetHashCode();
}
}

And then use it as:

var u = list2.Intersect(list1);

Garbage collection is probably not the answer to your question. Something is most likely holding on to your references, making it impossible to collect as garbage, even if you call Dispose(). I would use a memory profiler to find out. CLR profiler is free and easy to use. It can be found at Microsofts website: http://www.microsoft.com/download/en/details.aspx?id=16273[^]

//daniel