SharpDevelop Community

Get your problems solved!
Welcome to SharpDevelop Community Sign in | Join | Help
in Search

Daniel Grunwald

  • Translations of SharpDevelop

    Unlike SharpDevelop 3.2, which was available in 18 languages, SharpDevelop 4.0 (in its default configuration) will only support 13 languages:

    We had to drop the following languages because they were unmaintained and were lacking translations for too many strings:

    • Chinese (Simplified)
    • Hungarian
    • Italian
    • Romanian
    • Swedish

    For this purpose, we defined the cut-off to be 25% of the total amount of string resources for SharpDevelop (currently about 2600): the above languages were excluded because they have more than 650 missing strings.

    However, we decided to include some of the incomplete translations with SharpDevelop, they are just disabled by default. Qualified for this inclusion are languages with less than 50% of translations missing: the five languages mentioned above, and Russian.

    By editing C:\Program Files(x86)\SharpDevelop\4.0\data\Resources\Languages\LanguageDefinition.xml (assuming the default installation location), you can enable these partial translations. The file also contains out-commented entries for other languages that were dropped long ago - enabling those won't have any effect as these languages do not ship with SharpDevelop.

    If you want to revive one of these old translations, start a new translation, or simply join one of the existing translation teams, please contact Christoph Wille (christophw <at> You will get access to a Web application that can be used to enter translations online. The database behind this web application is then used to generate the resource files for SharpDevelop (please do NOT translate the .resx file!).

    Looking at the currently shipping translations, Dutch, French, German, and Spanish (both versions) are doing fine [thanks to the respective translators!], but it seems that Czech, Korean, Norwegian, Polish, Portuguese, and Turkish could use some help.

  • Source Code Repository Migrated to GitHub

    Last Saturday, we migrated our self-hosted Subversion repository to git and started using github for hosting.

    As part of this change, the SharpDevelop repository was split up in three parts:

    The SharpZipLib repository was migrated as well.

    You only need the main repository to compile and extend the SharpDevelop code.

    As part of this change, I also added a simple Git AddIn to SharpDevelop 4.0. It allows invoking the TortoiseGit commit dialog from the SharpDevelop project browser.

    With the move from Subversion to git, we also had to change the way we handle version numbers. Git allows distributed development and encourages branching, so it impossible to assign a simple increasing number to commits.

    So instead, we now calculate revision numbers based on the history: we count the number of commits between a known starting point and the current version. At least for the builds produced by our build server, this gives the illusion of an increasing revision number. Moreover, anyone checking out the same commit from git will calculate the same revision number. However, the numbers are not unique for builds created on different branches.

    The counting is done using: git rev-list 6eceaaafce5ed9b45d19a1645b1b012675aac996..HEAD | wc -l (the hash is the known starting commit)

    In fact, the numbers are now counting independently on each branch, synchronizing only when branches are merged into each other. For this reason, SharpDevelop now stores additional information about the commit it was built from:

    • Version number
    • Branch name (for feature branches)
    • Short commit hash

    The same information is shown in the version info inside crash reports. Note that the branch name is included only for feature branches - the "master" branch and branches starting with a digit are considered version branches and will not be shown. The feature branch name will also be shown on the SharpDevelop splash screen.

    For the purpose of looking up "which build corresponds to this commit" (or vice versa), we made our build server push this information into the git repository. For example, if you take a look at the commit b6f4ade7, you will see a "git note" at the end of the github page which says "Build on master successful".

  • Compiling for .NET 4.0 without installing the Windows SDK

    If you've tried to compile for .NET 4.0 using MSBuild on the command line without having the Windows SDK or Visual Studio 2010 installed, you'll probably have noticed this warning message:

    warning MSB3644: The reference assemblies for framework ".NETFramework,Version=v4.0" were not found. To resolve this, install the SDK or Targeting Pack for this framework version or retarget your application to a version of the framework for which you have the SDK or Targeting Pack installed. Note that assemblies will be resolved from the Global Assembly Cache (GAC) and will be used in place of reference assemblies. Therefore your assembly may not be correctly targeted for the framework you intend.

    Additionally, if the target platform of your project is set to AnyCPU, MSBuild will copy several files from the .NET Framework into your output directory:

    • mscorlib.dll
    • norm*.nlp
    • System.Data.dll
    • System.Data.OracleClient.dll
    • System.EnterpriseServices.dll
    • System.EnterpriseServices.Wrapper.dll
    • System.Transactions.dll
    • System.Web.dll

    This happens even if your project doesn't reference any of the named .dlls.

    So what are these "reference assemblies", are why are they needed for compilation? First, let's look back at .NET 2.0 (which didn't have reference assemblies) so that we can understand the problem that Microsoft wanted to solve.

    In .NET 2.0, MSBuild tells the compilers to directly reference the assemblies from the Framework's directory. The problem was: when .NET 2.0 SP1 added new classes and members, developers could accidentally use the new classes and make their program incompatible with the unpatched .NET 2.0.

     In .NET 4.0, Microsoft solves this problem by separating the assemblies used for compilation from the assemblies used for runtime. When you install the .NET Framework, you only get the runtime assemblies (installed in the GAC). These may be patched by hotfixes or service packs. However, the patches will not touch the separately installed reference assemblies: the compiler will continue to check your code against the original .NET 4.0 API. In fact, if you try to open the reference assemblies in Reflector, you won't see any code: these assemblies have only the metadata and do not contain any IL instructions. They are intended as a API reference only.

    But, while reference assemblies certainly are a good idea, not everybody has them installed. The ".NET 4.0 Targeting Pack" is not available as a standalone download, the only way to get it is to install the Windows SDK 7.1 (a 585 MB download) or to install Visual Studio 2010. So we decided that SharpDevelop 4.0 should be usable without having the reference assemblies installed. You won't get their benefits (when the .NET runtime gets patched), but you should be able to work as you could with .NET 2.0.

    So what did we do? First, I implemented a workaround for the "copy local" bug. I don't know why that bug occurs only when targeting AnyCPU, but I understand why this depends on the reference assemblies: MSBuild uses a file called "RedistList\FrameworkList.xml" to decide which references should, by default, be copied into the application directory, and which are part of the .NET framework and thus always present in the GAC. This file is part of the reference assemblies, so MSBuild must be using something else when those aren't installed. The workaround in SharpDevelop adds a custom MSBuild task to the assembly resolution target, which sets CopyLocal=false for all .NET assemblies (for this purpose, SharpDevelop contains a hard-coded list of .NET assemblies).

    Second: I found the MSBuild warning really annoying - it appears once per reference, so that's a few hundred warnings in a large solution. SharpDevelop 4.0 now simply ignores MSB3644.

    Together, these two small changes make builds of .NET 4.0 projects work as expected, even if no Windows SDK is installed.

    By the way: you can also use our workaround for the "copy local" bug in command line builds: call MSBuild with the parameter /p:CustomAfterMicrosoftCommonTargets=path-to-sharpdevelop\bin\SharpDevelop.TargetingPack.targets

  • File Encoding in SharpDevelop 4.0

    Today I have implemented support for choosing the file encoding when loading and saving files inside SharpDevelop.

    The option to specify an encoding while opening a file is placed in the "Open With" dialog. In earlier SharpDevelop versions, this dialog was available only in the project browser's context menu; in SharpDevelop 4 you can now "open with" any file using the main menu:

    Inside the "Open With" dialog, pick the entry "Text editor (choose encoding)".

    After that, SharpDevelop will prompt you to specify the file encoding to use for loading the file. The initial selection of the combo box is the automatically detected encoding that SharpDevelop would normally use.

    How does encoding auto-detection work? First, SharpDevelop checks whether the file has a byte order mark for UTF-8, UTF-16 or UTF-32. If it has, the encoding is trivially detected. Otherwise, SharpDevelop will parse the file and check whether the file is valid UTF-8. If it is and has some bytes >=128, the file is auto-detected to be UTF-8. The UTF-8 encoding is quite restrictive, so false positives are rare.

    If the file is invalid UTF-8, or if it is a plain ASCII file (no bytes >=128, which is always also valid UTF-8), then we will avoid reading the file as Unicode. Instead, we pick the encoding specified as default in the SharpDevelop Load/Save options. However if that encoding happens to be a Unicode encoding (it'll be UTF-8 by default), then we pick the current Windows ANSI codepage instead. This is done because we already detected the file to be non-UTF8.

    This means when loading a plain ASCII file and with the SharpDevelop encoding setting of UTF-8, we will still fall back to the ANSI codepage. The reason for this is simple: SharpDevelop always includes the byte order mark when saving files, and we want to avoid adding one to plain ASCII files.

    When saving a file, SharpDevelop will always use the encoding that was detected (or specified) when loading the file. Starting with SharpDevelop 4, you can use "File > Save with encoding" to save the file using a different encoding instead.

    A related feature that already existed in SharpDevelop 3.x is that SharpDevelop will warn you if a text file cannot be saved using the current encoding:

    In this screen shot, Martin's last name cannot be represented in the file's current encoding. Clicking on "Continue" would replace the 'č' with a 'c'.

    So let's summarize what the "default file encoding" option in the Load/Save options panel does: It's main job, of course, is to specify the encoding used for new files created with SharpDevelop. As a side role, if you use a non-Unicode encoding for this option, then files that were auto-detected as non-Unicode will be opened using that encoding.

  • Progress in SharpDevelop 4.0

    SharpDevelop execute many tasks that require progress reporting. Most also can be cancelled by the user.

    Examples are:

    • Loading a solution (parsing files for code completion and class browser)
    • Building
    • Searching

    In SharpDevelop, I've rewritten the IProgressMonitor interface used for these operations. The main difference in comparison with the old interface is that it is now possible to create nested progress monitors, allowing the composition of large progress-reporting operations from many smaller operations. Also, creating nested progress monitors now allows to safely report progress from parallel computations. Every thread can create its own nested progress monitor for reporting its progress.

    Now what happens with these progress reports? They will be collected by the ProgressCollector class. The ProgressCollector takes care of summing up the progress from all nested progress monitors. It also handles the multi-threading issues. The output of a ProgressCollector is a simple set of properties describing the current progress of the operation, plus a "PropertyChanged" event which will be fired only on the GUI thread. This allows using WPF data binding to display the total progress in a progress bar.

    Another difference is that the cancellation support has been simplified by making use of the .NET 4 cancellation framework.

    The above changes don't have any visible effect for the end-user. However, while working on this, I had an idea: similar to the progress bar in Windows Explorer in Vista and Windows 7, the progress bar should turn red when there are errors. This gives immediate visual feedback that the build failed, making it a lot less likely that you miss the error messages in the "Errors" pad and wonder why your binary didn't change.


    A related change in SharpDevelop is that the progress is now shown on the Windows 7 task bar:

    So the progress of long-running builds is always visible; even if you minimize SharpDevelop and do something else while the compiler is working.

More Posts « Previous page
Powered by Community Server (Commercial Edition), by Telligent Systems
Don't contact us via this ( email address.