Friday, February 17, 2012, 09:19 AM - Code Style EnforcerCenito Software AB, the company I now work for, has acquired the rights for Code Style Enforcer. This is very good news since it hopefully means that there will be more time for improvements and new features.
Code Style Enforcer 3.5 is now here, and better than ever. A reworked and more flexible rule system is now in place, where it is possible to override rules for specific code types based on modifiers and visibility. For example, we might want some specific name rule for parameters marked as ref or out, or we require public visibility on static methods, but any visibility on instance methods.
A new default name rule override has been added to the standard rules, namely that methods marked with the async keyword must have “Async” as suffix.
Please give this new version a try and let me know if there are any issues with this new rule system, or any other issues for that matter.
Be sure to use DXCore 11.2.7 or later, since the new rule system is dependent on this release.
• A redesigned and more flexible rule system supporting more granular name and visiblity rules based on not only the code type, but also on modifiers and visibility.
• The separate rule configurator application has been removed and both local and global rule configurations can now be made within Visual Studio instead (Tools menu --> Code Style Enforcer). This also solves the problem where the configurator application stopped working for each new release of DXCore.
• Code rules can now be saved upon change even if rule files have become readonly, e.g. by using TFS in offline mode.
• Due to changes in the code rule definitions, any old customized code rules will get backed up and the new default rules will instead be loaded, when opening the Global Code Rules Options dialog in Visual Studio or a previously Code Style Enforcer activated solution.
Download Code Style Enforcer 3.5.17
Wednesday, July 13, 2011, 06:09 AM - Windows Phone 7I recently upgraded my Windows Phone 7.0 project to 7.1 (Mango), by simply changing the Target Windows Phone Version setting in project properties.
After that I wanted to utilize the SavePictureToCameraRoll feature, but this call always throw an InvalidOperationException simply stating, "An unexpected error has occured.".
Trying the same thing in a new project worked like a charm, so after some digging and file comparisons I found that the WMAppManifest.xml file is not "upgraded" when changing the target version to 7.1, and in order to be able to call this method the ID_CAP_ISV_CAMERA capability must be added.
I hope this can save someone else's time!
Sunday, July 10, 2011, 08:19 PM - Code Style EnforcerCode Style Enforcer 3.0.72 rebuilt against new version of DXCore 11.1.5.
Download Code Style Enforcer 3.0.72
Thursday, July 7, 2011, 12:29 PM - Code Style EnforcerCode Style Enforcer 3.0.71 rebuilt against new version of DXCore 10.2.9.
Download Code Style Enforcer 3.0.71
Thursday, July 7, 2011, 07:26 AM - GeneralWe use Mercurial and TeamCity as CI server and have been experiencing some problems lately when developers are pushing Hg change-sets to the server when a build is in progress. The problem is that TeamCity first pulls and updates before starting the build and then during the build some files are generated and/or updated, like help files and version files (but also the .hgtags file). Then as the final step in the build process when it’s time for TeamCity to commit and push the changes there will be a problem if a new push has been made since the start of the build process, i.e. we will get an error message like "push creates new remote heads".
One solution to this is of course to pull, update, merge (if needed) and commit, or the Hg Fetch extension, but what we really wanted was to somehow prevent developers to push change sets into the remote server repository during the build process of that specific project in TeamCity.
After quite a lot of research on Google, I still couldn’t find any existing solution to this, so I started thinking about how we could manage this ourselves. The solution I came up with was to develop a very simple, but yet quite smart, REST service hosted on the same machine as the Hg repositories. The service exposes endpoints for EnablePush/DisablePush together with the name of the target repository. What the service implementation does is then to temporarily change the hgrc file in the repository to disable push, but not for everyone, since the automated build account used by TeamCity for Mercurial still needs Push access (allow_push = Mercurial). In order to enable Push again when the build is completed we then allow everyone with an account in the AD to Push again (allow_push = *).
In order to use the REST service from TeamCity I discovered a very useful plugin called tcWebHooks that allows HTTP POST on TeamCity events like build started and build completed. Here is a configuration example of tcWebHooks for enabling/disabling Hg Push for a specific project and repository using the custom made RIA service.
If you’re interested in the service install package or source code, let me know and I’ll send it to you!