Why would Visual Studio/CLR produce a "bad" executable?

Question

This is a weird problem I have started having recently. My team is developing a COTS application and we have a few people with their hands in the code. A few weeks ago, I received an error message when trying to debug (and run the compiled EXE):

"Windows cannot access the specified device, path, or file. You may not have the appropriate permissions to access the item."

It ended up I had to refactor this snippet of code:

mcolSchedulesNeedingOverride(New Guid(lstrErrorParts(0))) &= vbNewLine & lstrErrorParts(2)

In to this:

Dim lguidKey As New Guid(lstrErrorParts(0))
Dim lstrErrorMsg As String = mcolSchedulesNeedingOverride(lguidKey)
lstrErrorMsg &= vbNewLine & lstrErrorParts(2)
mcolSchedulesNeedingOverride(lguidKey) = lstrErrorMsg

That then allowed VS to generate a EXE that actually worked. I really don't understand why, but it worked. I did use the peverify utility to determine which assembly was having an issue.

Now I have the same issue in a different code branch after about 25 files were updated yesterday. This is NOT going to be fun to track down - so I was hoping someone could offer some insight as to why this might be happening - and that might help me narrow down where to look.

peverify shows all our assemblies to be correct, but is spitting back 90+ errors for System.Windows.Forms.dll!

Anybody have any tips?

Answer 1

You say that you have several developers working on the project, so I wonder whether they experience this problem as well.

If it is only happening on your machine than I would not go searching for a problem inside the code (the refactoring that you did seems quite unrelated to the error so I guess the reason why it was working afterwards was another) but go looking for a problem in your environment.

Maybe something is broken or incorrectly configured with you .NET Framework installation. Can you see which file is throwing the error message? Any policy defined for any assembly on your machine?

Regards, divo

Answer 2

I most commonly encounter that error message when I pull a binary off the net/some untrusted location. Windows will be "helpful" and block access to it.

Right click the file and choose properties, then 'unblock'

It's strange that the error manifests itself differently elsewhere, so this may be totally unrelated; but building on your machine would have windows treating the file differently than a downloaded copy...not sure how that relates to a reboot though.

Edit: see this kb article for a more thorough description of the "functionality" I was referring to