Heath, Thank you for taking time with my question. All references, as stated in the problem definition, are set to CopyLocal=True, yet indirect dependencies (references of references) are not copied, at least not file references. Looking at the various projects in my solution, I see the Project references are linked to the 'obj' folder of the referenced project. Now I wonder when dependencies are copied and how they are determined, because this process seems to miss the indirect file references. Interestingly, however, the Deployment projects do a more exhaustive search along the dependency hierarchy because it finds many related files. My solution uses MS Commerce Server and some of the projects have two dozen or so dependencies, most of which don't need to be deployed because Commerce Server is a product pre-installed on the target machines. While writing this reply, I created a small sample project to illustrate my point. In the sample, App1.exe has a project reference to ProjRef1.dll. ProjRef1 has a file reference to FileRef1.dll (which is not part of the solution) and, naturally, it works correctly. Maybe there's a problem with the size of my solution (30 projects).

I'm having a problem in VS2K3 whereby a file reference of a project reference isn't being copied to output folder upon compilation. Here's the solution structure: ProjectA References Assembly1.dll (File reference; CopyLocal = True) ProjectB References ProjectA (Project reference; CopyLocal = True) After compiling: ProjectA's output folder contains: ProjectA.dll Assembly1.dll ProjectB's output folder contains: ProjectA.dll ProjectB.dll (but not Assembly1.dll) Has anyone seen or resolved this? Craig Boland

Good call. Thanks for the reply.

My class contains an unmanaged system object member (a user profile handle) that is initialized in the static constructor. Conversely, I need to free the object when the class (not object instances) is destroyed, but I've never heard of a static destructor. Perhaps I could use Environment.HasShutdownStarted in the finalizer, but all instances could have already been gc'd when the AppDomain unloads and the code wouldn't run. Perhaps I could use the AppDomain.Unload event to run my code. Any thoughts?

I did something like this on a project. My solution was a variation of the GoF Bridge design pattern. The idea is to separate the abstraction (the base WebDocument class) from its implementation (child classes of WebDocument). 1. Make WebDocument an abstract class, so it can't be instantiated. Add a method that child classes must override that will be called to process themselves (i.e. Process). Create a static factory method on WebDocument to instantiate an the appropriate handler class. You'll need to pass some information into the method so the class can decide which to create (the HTTP header, etc.). public abtract class WebDocument { protected HttpRequest Request; public static WebDocument CreateInstance(HttpRequest r) { switch r.ContentType { case "text/html": return new HtmlDocument(r) break; ... } } public abstract void Process() } 2. Create a class for each document type you need to handle (PDF, Word, etc.) that inherits from WebDocument. Create something like UnhandledDocument to process documents that you don't currently support. public class HtmlDocument : WebDocument { public HtmlDocument(HttpRequest r) { this.Request = r; } public override void Process() { // do something with this.Request } } 3. Write client code something like this: HttpRequest req = HttpContext.Current.Request; WebDocument d = WebDocument.CreateInstance(req); d.Process(); Can you see how the abstraction (WebDocument) is separated from an implementation (HtmlDocument)? Supporting new document types is as easy as creating the implementation class and adding it into CreateInstance, and will affect no other code. The client doesn't know or need to know the instance type. All it is responsible for is getting an instance of WebDocument to process a request. Hope this helps. It certainly helped me!

I'm working on a WinForms app and need to embed an instance of MS Excel in a WinForm window. We did this in VB6, but it's quirky because we don't know Win32 API programming very well. I've got a sample of this, but don't see a way to post it along with this message. If I get a good solution to the problem, I'd like post an article on the topic for all to use. Can anyone offer help with this?

I solved the problem, which had nothing to do with the XPath queries. My XSL stylesheet is a Content file in a VS.NET project. I forgot that VS DOESN'T copy content files to the output folder. Thus, all of my stylesheet edits were never used! This is what I ultimately used to remove the nulls: translate(/myEl, '�', '') Does anyone know why VS doesn't copy content files to output folder?

I'm transforming xml and want to strip out null characters in the elements. The elements look like this: ��� My XSL rules look like this: For the 'select=' attribute, I've tried: - translate(/myEl, �, 'x') - translate(/myEl, '�', 'x') - translate(/myEl, '�', 'x') - translate(/myEl, '�', 'x') - translate(/myEl, '�', 'x') - translate(string(/myEl), '�', 'x') - translate(string(/myEl), '�', 'x') I've also tried at the root, but no effect. I'm translating null to 'x' for now so I know that I'm capturing the nulls correctly, but never get a match; my output always has with nulls embedded in it. The output xml is otherwise well-formed. Anyone know what I'm doing wrong?

From your description, it sounds like the reason your code doesn't work as expected is because the loop is running on the server and is thus starting over each time. I have two that you could try, both are client-side javascript: Window.setTimeout(code, delay) - A string of script to execute after millisecods delay has expired. You could call a function that keeps track of which page to display next. setTimeout fires only once, so your function will have to reregister call setTimeout() as well. Window.setInterval(code, interval) Window.setInterval(func, interval, args...) - Similiar to setTimeout, but repeats perpetually. The second overload may be the most appropriate for your problem. HTH

Has anyone heard of this class? I came across it in a custom config section handler I built on v1.0 (derived from System.Configuration.DictionarySectionHandler). The Create method loops thru an XMLNode to retrieve config file section settings. In v1.0, only ConfigXmlElement objects were in the enumerator (or so it seems). In v1.1, I'm also getting ConfigXmlWhitespace objects. My previous code: IEnumerator enumer = section.ChildNodes.GetEnumerator(); The workaround: IEnumerator enumer = ((XmlElement)section).GetElementsByTagName("myTag").GetEnumerator(); The workaround ensured that only XmlElements named "myTag" would be included in the enumerator.

You can put your settings in machine.config and it will pick them up. If you have Fx v1.0 and v1.1 installed, you'll have to use the machine.config for the version of Fx that your app is running under.

So you need your component to start when a message is received on the queue? If so, you can use MQ Triggers. Triggers are containers for Rules applied to a queue. By creating Rules, you configure the rule to invoke a method on a COM object or start en EXE. Create your Rules, then create a Trigger on your queue to apply the Rules.

Do your testers have Flash installed on their machines?

Does anyone know what factors affect the memory size an object will consume by simply creating a new instance? I know that member-level value-types will consume memory respective of their data type (Int32 consumes 4 bytes, etc.). What about code? Does a class that contains no member variables, but 2000 lines of code consume any memory by simply instantiating a new one?

When a form is closed, it disposes of itself. You may still have a valid reference to the form and it won't be null/nothing, but it is a useless reference: any access to it results in ObjectDisposedException. Make sure you aren't trying to access properties/methods after it has closed.

You could also use Activator.CreateInstance. This is much simpler that using AppDomain.CreateInstance, especially if the "Employee" class is in the same assembly. It also returns an Object instance instead of an ObjectHandle.

Interesting problem. You only need to implement IDisposable if you have either unmanaged resources (i.e. window or other object handles from the OS) or scarce managed resources (i.e. database connections). All other managed classes, including arrays, should be collected by GC periodically. In fact, implementing IDisposable imposes a small performance penalty when it comes to garbage collection. Not that you should never do it, but only do it when necessary. I have heard of other situations like this. I don't know if it was a problem with the Framework or simply sloppy programming. You may look into using structures instead of classes, if your classes are very simple and contain mostly primitives. Structures can have constructors, properties and methods. They are like light-weight objects, but are created on the stack instead of the heap. HTH

I must be missing something in your problem statement, but here's what I'm thinking. If you add an event handler to an object and that object fires the event, your event handler will execute. Subsequently adding the object to a collection has no impact on the event mechanism. Are you trying to work with events raised by the collection itself, such as when items are added or removed?

This cannot be done using VB6 alone, which creates only stand-alone EXEs or COM components. Desaware, however, has a product called SpyWorks, that will create Win32 exports of VB DLLs. http://www.desaware.com/SpyWorksL2.htm

Constructors don't need to be explicitly overloaded like other methods. You can simple create all of the New methods (constructors) you want, as long as they have unique signatures. If you rename the method to something like MyNew, it becomes an instance method and will not be used as a constructor.