multiple exes, one app.config

I wrote earlier about multiple exes sharing one app.config.  The problem is that .net doesn’t really support dll.config, so each exe project needed app.config files that were exactly the same.  This problem is made worse because if you use the user settings file (*.settings), the configuration information is stored the the app.config of the same project. 

I fixed the problem by using a reference to the common app.config file of the dll by editing my .csproj file to point to the dll’s app.config.  I don’t think this can be done in the UI, but VS does display the files with a little shortcut indicator.  To reduce confusion, I added a post build event to delete the *.dll.config file.

Edit:  References can be made to other files in the UI using “Add Existing Item”, then if you click on the dropdown next to “Add” in the open file dialog, select “Add As Link”

making time estimates

when i switched to strictly dev work, i thought that i would have a hard time with giving and meeting work estimates because i’m a slow coder.  turned out that i’m not that bad.  i think i just have to double my initial idea of what it would take because i don’t take into account everything i need to do.

for next time:

1. get a feature list.  this last time, my boss kept adding on stuff.  not that he expected me to be on time with the extra stuff, but it still helps when designing and planning
2. prototyping, proof of concept… (can i read the bytestream records off the socket connection?)
3. is there a client ui?
4. working with unfamiliar code?
5. functionality testing
6. perf
7. refactor, review code
8. other work being done in parallel

marshalling byte arrays into data structures

After writing a program and benchmarking, it turns out that Marshal.PtrToStructure took up about 1/4 of my app’s cpu consumption!  It just so happened that a few days ago, an article was written on this exact subject (http://www.codeproject.com/KB/dotnet/ReadingStructures.aspx?display=Print)

Unfortuantely, I couldn’t use his best optimization (60x faster) because I used a class, which is managed, so the pointer stuff doesn’t work.

Using fixed instead of GCHandle yielded a 20% perf gain.  Doing the exact operations on structs was 2x faster for GCHandle and 3x faster for “fixed”.

Overall, my perf isn’t that bad, so it’s not worth doing these things.  One option was to make my class into a wrapper class for a struct, but that seems like just too much effort.

datetime.utcnow 40x faster than datetime.now

DateTime.UtcNow is over 40x faster than DateTime.Now in c#.

DateTime.UtcNow.AddHours(-5) is 20x faster than DateTime.Now.  this doesn’t work in practice because you have to account for daylight savings time… and there’s no fast built-in way to do it

so if perf is critical, avoid using local time

wcf mex endpoints and app.config

i refactored my code and put the wcf service in a separate dll, and the service discovery stopped working.  spent a couple hours trying to figure out how i could get it to work with the service info in the dll config file, but it just doesn’t work.  you just have to leave it in the exe config files i guess. 

its not that bad, but in my case, it forces duplication of information since i have multiple exes calling this library.

Hello world!

Welcome to WordPress.com. This is your first post. Edit or delete it and start blogging!