October 2004 - Posts
Try this out. Download Filemon. Add a filter for devexe. Open up the IDE, View Code or View Designer on a file.
There are literally hundreds of hits on this. I see lots of FILE NOT FOUND, PATH NOT FOUND. When I dig into these they appear to be mystery dlls or dlls that we file reference from the IDE and the IDE is looking in strange places for the reference.
Interesting stuff.
Tip of the day, when logging information for diagnosing a problem, or simply logging an error (log file, event viewer, etc) make sure you are logging the program's security context as far as the operating system system is concerned (Keith Brown: The .Net Developers Guide to Windows Security).
You will then know "Who am I?" We are doing this in our app and it has helped it some cases. Perhaps the user is being denied access to a secured resource and you do not know why. Know the WindowsIdentity.GetCurrent will help you figure out why.
Simply add this call:
Dim id as string = WindowsIdentity.GetCurrent()
the log this:
id.Name
for your User Name
BTW, the Application Exception Block does this for you (the default).
The below code makes sure that the user running this code is an Administrator:
Dim myDomain As AppDomain = Thread.GetDomain()
myDomain.SetPrincipalPolicy(PrincipalPolicy.WindowsPrincipal)
Dim myPrincipal As WindowsPrincipal = DirectCast(Thread.CurrentPrincipal, WindowsPrincipal)
If myPrincipal.IsInRole(WindowsBuiltInRole.Administrator) Then
When running this code on a Windows 98 machine, you get a vague security exception:
"Application has generated an exception that cannot be handled"
From Microsoft:
"It makes sense that we are seeing this exception on Windows 98 because there is no Administrator role, or even a concept of any role. Obviously we need to correct MSDN Help which incorrectly states that IsInRole is supported on Windows 98. There is a second issue here in that, you can also generate this exception on a Windows XP machine by calling the overloaded IsInRole method that takes an Integer (as you are doing) and pass it a Role ID (RID) that does not match any known RID. You may want to put your code in a Try...Catch block and handle the System.ArgumentException."
The solution, wrap this check with a check on the OS:
Dim strOS As String = System.Environment.OSVersion.ToString()
Dim strWin98 As String = "Microsoft Windows 98"
Dim intReturn As Integer
intReturn = strOS.IndexOf(strWin98)
If intReturn = -1 Then
This bad boy just landed on my desk. I am sure it will take me a while to read this.
If it's anything like Keith's first security book, it will be an awesome read.
I completed reading this book over the weekend. Rather than do an overall review, I will do a chapter-by-chapter review.
· Chapter 1:Hidden Treasure in Visual Studio
o I really enjoyed reading this chapter. The chapter moved fast and hit you with lots and lots of tips, all worth knowing. I knew most of them though. I did pick up a few new ones that I added to my toolbox of tricks. This is a great chapter for a beginner or for someone who has been using the IDE for 6 months to a year.
· Chapter 2: Doing Windows Forms
o I also enjoyed this chapter, mainly because I am working on a Windows Form application right. A lot of good tips and design suggestions. This is a great chapter for a beginner or for someone who has been using the IDE for 6 months to a year.
· Chapter 3: Code Tricks
o Lots of good information in this chapter. I use most of these tips already, though; once again I did pick up a few along the way.
· Chapter 4: Much ADO
o I was disappointed with this chapter. I really did not see that many tips or tricks, though I am an intermediate to advanced ADO.NET. Perhaps this is why I did not learn that much in this chapter.
· Chapter 5: Defensive Development
o I struggled with reading this chapter. Mainly because it was more about design and development that it was about tips and tricks in .NET. I am not sure how this chapter fits into this book, or why it was included.
Overall, this is a good read for a junior to intermediate .NET developer. If you have been working with .NET for 6 months to a year, pick this one up. If you have been working with .NET for longer than a year or 2, you probably will not take too much from this book.
I give it a 3 on a 5 scale.
I usually do not do this or use this forum to plug a 3rd party vendor, but I have to ;-)
We purchased Janus windows forms controls approx 2 years ago, mainly for their GridEx.
The grid is all that and then some. Our users are very pleased. What we did not know was how awesome their other controls are, AND, how awesome their support is.
I can think of at least 10 times off the top of my head where we had an issue with a control, specific to our application, where we asked them what they could do for us, and, within 1-2 days we had a patch.
They just released v2 of their controls. We liked their v2 toolbar over the current 3rd party toolbar we are using, though it was missing one feature. We emailed them and asked them what they could do. In the interim we found a work around.
2 days later they added logic for our case and sent us a patch.
All I can say is, if you are in the market for a suite of awesome controls, give these folks a look.
Our intern started this week. He comes in from 1-5pm. We have him looking at FxCop, Nunit and Draco for us. Things we want to implement, just no time. I could give him a hammer and some nails and he would have a house built in a week; he is that smart.
He is very polite, very professional, and somewhat shy, though I am certain that will change after a few weeks with us ;-)
He's from Nigeria so I am excited to learn about his culture. It was 44 degrees the other morning, probably mid 60's by 1pm when he came in. He had a winter coat on. I asked him if it was cold outside, and he said, "Yes!". I walked outside in a short sleeve shirt and was quite comfortable. I guess compared to Nigeria it is cold.
"Debugging is twice as hard as writing the code in the first place. Therefore, if you write the code as cleverly as possible, you are, by definition, not smart enough to debug it."
--Brian Kernighan
We have a Windows Forms application with controls bound to a parent row and a child row. When we change the primary key value in the parent table (at runtime per some user action), we do not see a different child row in the controls bound to the child datarelation . We have cascading updates turned off so the child key values do not get changed.
I worked on this for 8+ hours. I finally gave in and called Microsoft.
The result:
"Initial Analysis: I can reproduce the problem. The problem is with the DataRow.GetChildRows method. It still returns the old child row even after the key value has been changed and AcceptChanges has been called. Deleting and re-adding the DataRelation was the only way I could work around this issue, which should not be necessary. A second issue appeared in that once the GetChildRows method was worked-around, the child CurrencyManager still pointed to the original row and not the new child row. To work around this, I had to replace the Form's BindingContext with a new one. Once this was done, both the CurrencyManager and the controls it managed got updated with values from the correct child row.
<Action Plan>
Neither of these workarounds is acceptable so I am going to file a bug with the development team"
Wonderful, we found yet another bug in the framework.
More Posts
Next page »