Migrated to Blogger

Because ebloggy does not support syndication, I am now using http://jiwhite.blogspot.com/ as my personal blog.

Heard around the office this week ...

"He went from drinking the wine to stomping the grapes."
- Kevin Hill

Favorite photo comment of the day

I've been uploading my photographs to flickr.com.   I tried posting one of my photographs to a critique group today.  My favorite comment was, "Reminds me uncomfortably of some strange, SF weapon, pointed directly at my face. And that's the best thing about this picture," by Xot. LOL


 
http://flickr.com/photos/janine-white/20399734

"If you're calling me for this, you don't know how much trouble you're in for."

I  was getting the following kinds of errors when compiling Visual Studio .NET 2003 solutions.

Error: The dependency 'CONTROL, Version=VERSION1, Culture=neutral' in project 'PROJECT' cannot be copied to the run directory because it would conflict with dependency 'CONTROL', Version=VERSION2, Culture=neutral'.

I tried deleting all of the bin and Debug objects, then recompiling.  No luck.  I tried removing, then readding references, then recompiling.  No luck.  I tried editing the Project file in Notepad to change the order the assemblies are compiled in.  Still no luck.  However, then I noticed that some of my references to controls were directly to DLLs, while others were to projects.  By removing the references that were directly to DLLs and replacing them with references to projects, the issue was resolved.  By using different kinds of references during compilation, both references to old and newer versions of the controls were being attempted to be compiled at the same.  Using references to projects ensures that only the latest version of the control will be compiled.

The process cannot access the file because ...

An error I commonly encounter in Microsoft Visual Sudio .NET 2003 development while compiling projects is, "The process cannot access the file because it is being used by another process."  According to Microsoft, this is a bug as a result of .NET caching any files larger than 64K and having a solution that outputs multiple projects to the same folder and/or Copy Local is set to false on one or more assemblies.  In addition to the obvious resolutions of changing output location and/or setting Copy Local to true,  Microsoft also suggests closing the Object Browser window and making sure that a project is only open in one instance of Visual Studio .NET at a time.  I usually solve the problem by deleting everything in the bin directory of the project, then rebuilding.  Another workaround that has been reported is to change project build configuration from debug to release, to build the project and then switch back to debug configuration.

Intermittent ASP .NET Access is Denied error

I finally found a solution to a programming problem that has been wasting my time for months.  Approximately every other time (sometimes more) that I compiled an ASP .NET application, then tried to test the site, I would get and Access is Denied error indicating that there was a problem with the machine.config or web.config file while trying to load the assemblies.  The only reliable way I found to clear this issue was to reboot, which was wasting a lot of my time.  It turns out that the issue has nothing to do with the config files.  It is cause by the Indexing Service catching the files, even if the ASP .NET application doesn't use Indexing!  The best solution is to turn off the Indexing if you're not using it.  For example, on my Windows XP Pro machine, I went to Start>Administrative Tools>Services, right click on Indexing Service and select Stop.  I also opened up the Properties for the Indexing Service and set it to start Manually, instead of Automatically.

An excellent article on this topic is Access is NOT Denied!  Also, thanks to Eric Bowen's blog for pointing the way to it.