Wraith

MSDN - Basic Instincs - Deploying Assemblies You want a probing element that specifies the private bin path of your data folder.

The problem is that you don't understand regular expressions well enough to realise that the leading / and trailing /i in the pattern you're trying to use are nonsense. I think they're sed syntax but i don't really think it matters particularly, they're clearly not helpful to you. I stongly suggest you not use regular expression until you have some idea how they work, they're complicated and often subtle and if you rely on them to work without knowing when they're likely to fail you're going to end up missing or corrupting information in the rest of your application sooner or later.

Attributes are stored in the filesystem, they're metadata. If you mean properties then no there is no standard way of dealing with them.

System.IO methods do not allow stream syntax and do not check for reserved names. If you want to do these things you have to do it yourself.

It is the nature of single processor systems that only a single instruction can be executing at any one time. They take a very short amount of time so you can do lots of them together meaning that to slow moving things like people it can _look_ like there are multipe things happening at once. There aren't. One thing at a time on single processor systems, always. If you don't understand this then you need to, it is important and you're not going to use threading effectively or possibly even correctly until you do.

What new way is this? I've the express editions and have installed the service packs and i can't see any new way of doing things.

KeyedCollection Generic Class using System.Collections.ObjectModel; public class MyObjectNameKeyedCollection : KeyedCollection<string,MyObject> { protected override string GetKeyForItem(MyObject item) { if (item==null) { throw new ArgumenNullException("item","item is null"); } if (item.name==null) { throw new ArgumentException("item name is null","item") } if (item.name.Length==0) { throw new ArgumentException("item name is empty","item"); } return item.name } }

If you wanted to use the hashcode like that you'd need to override GetHashcode() and return a value derived from the content of the class rather than a strict identity value as it is now. It is inadvisible to alter the hashcode of something during it's lifetime, the same object should always return the same hashcode. Even if you decided to use this method i wanted to attack your application i'd just derive from your type and override hashcode to return the initial value which i'd save as a new field. Using Protected Private and Internal accessibility declarations as well as possible wrapper and immutable classes is probably your best approach.

Why are you using regex to do the path manipulation? Seriuosly considering using the Path static methods instead, if (Path.IsRooted(foo)) foo=Path.GetFileName(foo); for example. Similarly if you want to create a new path with the application current directory and the filename you should use Path.Combine() instead of manually glueing bits of strings together. You're making a component, which i'm going to assume really means you're deriving from Component (or Control or Form or some other class which either inherits from Component or implements IComponent) so instead of using the .Site property which can be null without first checking it (which can cause a NullReferenceException) why don't you just use the DesignMode Property which won't require you to use expcetion in flow control logic and will simply return a boolean value you can use to determine design mode status or not.

You don't need 2.0 to get a simple case insensitive hashtable, System.Collection.Specialized.CollectionUtils.CreateCaseInsensitiveHashtable() does exactly that for you and has been present since 1.0. If you are using 2.0 and you want a case insensitive string comparer it makes sense to use System.StringComparer.InvariantCultureIgnoreCase or System.StringComparer.CurrentCultureIgnoreCase rather than going to the trouble of writing your own. If you want an IDictionary with ordered why not look at the OrderedDictionary class that was added in 2.0? its in System.Collection.Specialized. It has a constructor which takes only an IEqualityComparer as an argument and helpfully StringComparer (and all its various static fields since they are derived from StringComparer) all implement IEqualityComparer and IEqualityComparer<string>. That means all you have to do is import System and System.Collections.Specialized and you can have a class that does exactly what you want with: IDictionary variable = new OrderedDictionary(StringComparer.CurrentCultureIgnoreCase);

I've been perplexed by this in the past. Mine is working now and i can't remember exactly which debugger options i had to change. I think you need to ToString() evaluation and JustMyCode enabled, give it a try.

When you leave things in it yes. when you remove those items you'll find it strangely undeletable from the ide.

The folder is a fake folder, its just some xml in the project file and can be easily removed simply by editing the project file in a text editor. The msbuild project syntax can let you do all sorts of things when you get started playing about with it

Application.Exit() is the rude way of tearing down the application. It doesn't ask the currently running form(s) to close, it just yoinks the environment out from under them which is why your breakpoints aren't getting hit. If you've not noticed any problems then you're lucky and all the things that aren't getting disposed were only scoped to your application so when the process dies they're effectively dead. Form.Close(), it closes the form and if that is the MainForm of the Application the Application will cleanly shut down the messageloop and continue through Main which is normally empty. Think about it. You started the application by creating a form and telling the application object to start sending messages at it (this is what Application.Run does) so to shut it down politely the form should tell the application that its all finished now thanks and then go away. Doing it externally from Application.Exit() isn't the form telling the application its finished.

A call to a virtual function should (and will) execute the most derived instance of the function present. So in your derived class the overriding function will be called unless you use some specific mechanism (the base keyword, or a direct typed reference to a base class in VB) If ot doesn't then theres something wrong with reality in your program. The behavior where the base version of a virtual function is called from a derived context without specific call to base is totally conter intuative and possible contrary to the runtime design. You expected the correct behavior. if this behavior isn't happening then there is something wrong. Make the base function abstract? afterall if its empty and virtual and inheritors are required to override then it pretty much already is abstract by agreement. Of course that means you'd need BaseClass ot be abstract which may or may not work for you. If you can repeatably make this weird behavior occur i'd like to see working code, inheritance doesn't work the way you say it seems to be and you shouldn't be able to do what you say you have.

They aren't errors, there is nothing wrong with the program that wasn't already wrong when you ran it on your own machine. Applications are granted security permissions to access resources and take actions based on things like their location who signed them and whether they are known to be from trusted sources or not. In thise case the person running your application is doing so in a way which means that the application is running as a limited trust app. Typically this is because people who are unaware of security are running them directly from the web or from a mapped shared drive. The quick fix is to move the application to a local drive which will cause it to run in full trust. The better but more difficult fix is to work out what permissions your application needs and declare the minimum permissions require by your application which will prevent it being run if those permissions can't be granted. From the small amount of the exception message i can see i'd say its failing on: Dim reader As New StreamReader(fileName)

If you're not averse to a little COM pinvoke you can just declare the IShellLink interface, ShellLink coclass and the associated bits and pieces (Win32FindData struct a few enumerations and various other things). Then wrap the IShellLink in a disposable object and you've something that'll let you deal with shortcuts easily.

I dislike things turning up in my compiled il that i didn't put there, VB takes Handles and generates a lot of delegate instructions and puts them where it wants them. Its a personal perference that i got into when moving from vb6 to c#, i really dislike things trying to be clever and altering what i've written behind my back. I've never said there is anything better about c# in this regard. I do think it is slighly cleaner because it limits itself to locally scoped generation like using() and lock() statements but i happily do without those as well. I find it disingenuous, it is allowing the old VB model to persist in a system which does not conform to that model much as AddressOf and AddHandler are, they're not OO and they just hide what really happens in peculiar syntax. I don't use VB because i don't much like it, i find it frustrating to work with becaause i constantly have to look up how the language abstracts the concept i want to work with. Thats my choice. On the other hand if that works for other people then i have no problem with it for the most part. What bothers me is there an explanation of something is incomplete of incorrect because the language is hiding important implementation details from the user.

It depends if the designer understands the change made and picks up the new value. At best it'll be left present or slightly altered by subsequent autogeneration. More commonly it just gets thrown away or causes an error to be thrown in the designer which can be a pain to track down. Chunks of autogenerated code are like any other code but i don't think autogenerated code which can have important causal affects on program functionality or stability are quite the same as a simple wrapper around a try-finally block, its a question of the affected scope not a question of auto generation.

You understand of course that Handles like AddressOf and many other VB keyword is merely a shim over the existing CLR functionality and doesn't actually exist when compiled. In the case of Handles the compiler simply dumps a lot of event hookup operations into the constructor of the instance which is pretty much identical to the C# way of putting them in the designer InitializeComponent method. If you like it that way then thats fair enough but it is generating a whole load of code behind your back that you get no chance to edit, personally i dislike that.

You can only edit resources in an assembly if its either unsigned or you can resign it, otherwise you're a bit scuppered. I use a native resources assembly (cunningly named %project%.NativeResources.dll) into which i build only a win32res .res file containing the icons bitmaps etc that i wish to be able to access directly from windows rather than managed code. I buil it either with a simply csc answerfile or an msbuild project and all i needed to do was provide the path to the .res file as the win32res parameter. How you create the .res file is up to you

In any function which occurs before it on the stack, so anything that sits between the Main method and the event handler method. That works, why do you think it doesn't.

Try cleaning and Rebuilding the entire thing instead of relying on previous intermediate files. Also try not making silly coding errors that cause warnings. YOu could also turn off the warnaserror setting if you really don't like it.

Person has an "is a" relationship with Entity, this means if A is a Person then A is an Entity, always. When assigning a more derived (Person is more derived than Entity, sometimes said Person inherits or is based on Entity) the compiler will attempt to find and use a lossless conversion between Person and Entity and because of the "is a" relationship there is a single cast operation which will do this. The cast does not alter the memory layout of the Person. The cast does not create a new Entity. The cast takes the typed reference and attempts to return a new valid differently typed reference. This will succeed and you will obtain a new reference to the same original memory area which you will now access through a different Type. No data loss, no data alteration, no data multiplication or creation. The only thing that changes is a single new reference and your view of the data you have. User defined cast operations can perform data changes and interpretations but i advise you against worrying about that until you need them. Person derives from Entity therefore Person "is a" Entity is always true. This rule is not reversible. If i create a new class Pet which derives from Entity then Pet "is a"n Entity but a Pet is not a Person. An entity "may be" any of the types derived from it. If and only if an Entity is also a Person then a cast operation to the more derived type will succeed. If Entity is not a Person then an InvalidCastException will be thrown. Because the cast operations do not change the data in the object the data in a Person is not lost zeroed or otherwise altered when you cast it to an Entity. For the same reason if you successfully cast an Entity into a Person then the data for that person remains unchanged from when you last accessed it as a Person instance. These are reasonably fundemental language principles. If you don't understand this you're not seeing the flexibility and power of the language or the framework and you should consider doing some reading about object orientation and object polymorphism as well as the c# language docs.