Question

At the end of the Quick Start Guide, there is a section about the automatic upload dir. I have added the _postbuildSln.bat file to my post-build step, and I can see that the new zip ends up here and disappears after a while (when the "heartbeat" picks it up, I believe?). But my plugin version stays the same. If I remove the existing plugin and install my new version (either by uploading it in the browser or by placing it in the upload folder), the new version does get installed.

I did change something in the code that I should see in the UI, and I changed the AssemblyVersion and AssemblyFileVersion attributes. Is there something else that I need to do so that FogBugz is convinced it can upgrade the plugin?

I am running FogBugz version 7.1.10 (I got it just for plugin development, without a maintenance contract, so I guess I get no updates).

Case FC1906133

Answer 1

Edit by Fog Creek: This is a bug. We have a case open to fix it. Thanks, Jan!

---

I found the source of the error: FogBugz was confused about the timezone offset of my computer, and this resulted in incorrect checks for the "freshness" of its plugin cache.

Workaround: I solved it by removing the plugin from the cache in the post-build step (which learned me more than I wanted to know about Windows commands).

Here are some notes about how the plugin upload system works:

Each plugin gets a record in the Plugin table in the database. Interesting columns are dtUpload and rgbFile. The first one contains the UTC time of the latest upload. The rgbFile contains the actual zip that is uploaded. These files are set in CPluginModule.UploadPlugin (which gets called by UploadFolder, which gets called by PullFromUploadDir or UploadFile). From what I learned, AssemblyVersion and AssemblyFileVersion are not checked: a zip in the upload folder ends up in the database, even if the version is lower.

The plugins are not loaded directly from the database, but from the cache folder. The CPluginModule.DumpCacheToDisk function is responsible for keeping this cache up-to-date. It compares the timestamp of the folder with the timestamp of the database. (This is where it went wrong for me: the timestamp of the folder is in local, or server time, and the conversion to UTC was one hour off.) If the timestamp in the database is older (or if the folder does not exist of course), the folder is created, the zip is extracted there and the code is loaded.

Answer 2

Through his excellent debugging, Jan has found a bug:

FogCreek.DateTime.TimeZoneHelper.GetServerTimeZoneOffset() returns an incorrect offset for me, while DateTime.Now.ToUniversalTime() gives a correct result

I have opened a case (number FC1906133) to fix it. If you have the same issue, take a look at Jan's workaround.