SharpDevelop

The installer for SharpDevelop 2.1, from revision 2245 onwards, now allows you to configure the file associations that are created. Previously the installer would register them without asking and you would lose any file associations that ... [More] Visual Studio had previously set up.When you install SharpDevelop you will now be presented with a dialog containing a feature tree.Expand the File Associations feature to see the list of file associations that will be created by default.From this dialog you can stop the installer from registering any file associations or you can disable individual file associations. To stop the installer from registering any associations, right click File Associations and select Entire feature will be unavailable.Disabled file associations will then be marked with a red cross.Individual file associations can be selected and disabled in the same way. [Less]

SharpDevelop is the program I use at home for all my .Net coding. At work I've used Visual Studio for the last couple of months, but I'm coming from a Linux background, and used mostly GVIM as my editor, that is the most common editor where I work ... [More] (Some say sadly...)As you can see, I've experienced  both low level tools and high level tools. I started using SharpDevelop because, like most people, I prefer the high level tools (the IDEs) and SharpDevelop was there and was free (recently Microsoft released Visual Studio Express, but it takes forever to install and takes about 1.5 GB, for nothing more than any other IDE would give).After a while working with  SharpDevelop, I started to feel that some things could be made better. As my work title is a software architect, I many times start my coding work in the Class Diagram view, drafting the architecture visually. This feature was missing for me in SharpDevelop. So I thought, why wouldn't I write an addin?I started working on my addin by looking for explanation and a starting point. I found the wonderful tutorial and video in the wiki, and started implementing. A couple of refactoring phases made the addin architecture nicer (note that it is not yet complete) and many elements were made reusable.During the creation of the addin I found that some features I want to use from within the addin are also missing from SharpDevelop:Class EditorClass Wizard The class editor is a fairly big feature allowing the editing of the class structure from a simple tree-grid-view, showing the hierarchy of the class (class->members->parameters) and allowing to add and remove members and parameters, while the code is changing accordingly.The class wizard is a simple code generator, that asks you to fill in some information about your class, like its name, the class from which it inherits, the interfaces it implements, etc... and it creates the code for you and add it to the project. A good class wizard allows you to fill in the bare minimum of required information manually, and creates the class respectively. The idea is that the class can and will be modified later on by the class diagram.Currently the class diagram is working fairly with quite some bugs (like layout) and missing features (like editing). The class editor does not allow editing at the moment and the class wizard is in its early stages, although today I managed to use it to create a new class in my project.Well, I'll keep writing (the addin and in the blog), and I hope to get things done soon.See you next time,Itai.  [Less]

SharpDevelop 2.1, as of revision 2135, now allows you to run your unit tests against .NET 1.1 or .NET 2.0. Which framework your tests are run under is determined by the target framework your test project. So if you choose .NET 1.1 as ... [More] your target framework, your tests are run in the .NET 1.1 framework. The project's target framework can be set by selecting Project Options from the Project menu, then opening the Compiling tab. Only .NET 1.1 and .NET 2.0 are supported, so if you choose another framework, such as one of the Compact Frameworks or Mono SharpDevelop will run your unit tests under .NET 2.0. There's currently no support for Mono because our modified nunit-console has a threading problem which happens very frequently under Mono, but never seems to occur under Microsoft's .NET Framework. Running under another .NET Framework Since SharpDevelop recently moved to using nunit-console to run unit tests it was a fairly simple task to make it possible to test against .NET 1.1 or .NET 2.0. It is straight forward because nunit-console can be compiled against .NET 1.1. Since SharpDevelop is launching nunit-console as a separate process we could have used one of the following to target one particular framework. app.config COMPLUS_Version environment variable App.Config Using an app.config file is the most obvious and well documented way to target a particular framework and is actually how SharpDevelop gets nunit-console to target the different frameworks. To run unit tests with .NET 1.1 we have nunit-console.exe built against .NET 1.1 and an app.config file, called nunit-console.exe.config which, contains the following: <configuration> <!-- The startup section may be used to specify the runtime versions supported in the order that they will be used if more than one is present. --> <startup> <supportedRuntime version="v1.1.4322" /> </startup> </configuration> Note that the actual nunit-console's actual app.config has some extra things which I have removed in the above example so it just shows what is needed to target a particular framework. The <supportedRuntime> element is used to determine which framework the application is run against. To run against .NET 2.0 we use the same copy of nunit-console, built against .NET 1.1, but with an app.config which has .NET 2.0 as the supported runtime. When you run the unit tests SharpDevelop looks at the project's target framework and runs the corresponding nunit-console. COMPlus_Version With Microsoft's .NET framework you can set the COMPlus_Version environment variable before running your .NET application to run it under a particular framework. So at the command line you could execute SET COMPLUS_Version=v1.1.4322 Then your application would run against .NET 1.1. Specifying a framework in your app.config will override the COMPLUS_Version setting however. SharpDevelop does not use this method since using an app.config makes it easy to support running unit tests with NCover and the debugger. Using COMPLUS_Version we could not run NCover since it is compiled against .NET 2.0. The debugger would also need to be modified so it could set environment variables before debugging an application. Mono How do we target another framework with Mono? You can use one of the following: app.config mono.exe --runtime command line parameter Again we can use the app.config file as discussed previously. We can also use the new --runtime command line parameter that was added in Mono 1.2.2. This works in a similar way to the COMPLUS_Version environment variable allowing you to set the framework version globally. Using the command line mono --runtime=v1.1.4322 nunit-console.exe would run nunit-console under Mono's .NET 1.1 framework. There is one difference though, specifying the target framework in the app.config does not override this command line setting. Code Coverage with .NET 1.1 If you want to look at code coverage when running your unit tests under .NET 1.1 you will need to use NCover version 1.5.4 since the latest release 1.5.5 does not work produce any coverage results when profiling a .NET 1.1 assembly. [Less]

I've just added a basic query tool feature to ServerTools->DbTools - right click on a logical db connection in the Server Explorer -> Database Explorer node, and 'Open SQL Tool' is available as an option. This opens a Form hosted in a ... [More] ViewContent with three tabs - one is an editor based on #D's TextEditorControl, the next hosts a DataGridView of the result set from any successful execution of the SQL entered in the editor, and the last hosts a TextBox which shows any messages or exceptions encountered. Right clicking on the text editor presents the option to dispatch the SQL to the server identified by the Database Explorer node from which the SQL Tool was opened.  The next feature I am planning to implement is SQL parsing and field name completion.                                       [Less]

The Unit Tests window in SharpDevelop 2.1 (revision 2039) has been changed in order to fix a few bugs and problems that it had. How you unit test in SharpDevelop is still the same, as explained in the Unit Testing feature tour, but ... [More] there are some new features shown below. Most of the changes have been behind the scenes so everything should look the essentially the same.New FeaturesUnit Tests window shows classes and methods obtained from SharpDevelop's parser.Unit Tests tree dynamically updates itself to show new test methods and classes as the parser information is updated.All tests are run using a slightly modified nunit-console.exe.You can now run all tests from all the projects with the debugger or with code coverage in one step. Previously you had to select an individual project in the Unit Tests window.Running a test with code coverage or with the debugger will now update the Unit Tests tree.Running tests from the Unit Tests window will use the test project's app.config so you can now run tests in a STA or MTA.The Reload and Unload toolbar buttons have been removed since they are no longer needed.Running Tests in a STA or MTABy default SharpDevelop runs tests in the MTA. This is the default behaviour of NUnit which is what SharpDevelop uses.To run your tests in an STA you can create an app.config file for your test project as shown below: <configuration> <configSections> <sectionGroup name="NUnit"> <section name="TestRunner" type="System.Configuration.NameValueSectionHandler" /> </sectionGroup> </configSections> <NUnit> <TestRunner> <!-- Valid values are STA,MTA. Others ignored. --> <add key="ApartmentState" value="STA" /> </TestRunner> </NUnit> </configuration>Unit Tests InternalsIn this section we will look at what is actually happening when you open a solution and then run its tests.Dynamically Updating Unit Tests TreeWhen a solution is opened in SharpDevelop any project that has a reference to the NUnit.Framework assembly will have a corresponding tree node added to the Unit Tests tree. Expanding the project node shows test classes grouped according to namespace. Expanding a test class node shows the individual test methods.What classes and methods are considered to be test fixtures and tests are all determined based on the information from SharpDevelop's parser. If a class has a [TestFixture] attribute then it is considered a test class. If a method has a [Test] attribute then it is considered a test method.The Unit Tests window will update itself as the parser notices changes in your code. So new test classes and methods will appear in the test tree as you type.Customised NUnit-ConsoleWhenever you run unit tests in SharpDevelop nunit-console.exe is involved. This NUnit-Console is a slightly modified version of that which ships with NUnit 2.2.8. It has three extra command line arguments:testMethodNameAdded by Daniel Grunwald in SharpDevelop 2.0. This allows NUnit-Console to run a single test and takes the fully qualified test method name.resultsUsed to specify the filename where the test results are written to as they occur.namespaceFilterIf this argument is used then NUnit-Console will only run the tests that exist in the specified namespace. SharpDevelop sets this argument when you select a namespace node in the Unit Tests tree and run the tests.As the tests are run SharpDevelop monitors the generated test results file. As each test result is added to the file the Unit Tests tree is updated with the usual red, green and yellow colours. Any test failures are added to the Errors window.Whenever you run a test or set of tests nunit-console.exe will be run, either by SharpDevelop itself, or by NCover when looking at code coverage, or by the debugger when you need to debug your tests.[Update 25th November, 2006]In revision 2076 you can now select a namespace node in the Unit Tests tree and run only those tests for that namespace. This was done by adding a new namespace filter argument to nunit-console.exe. The post has been updated to reflect this. [Less]

Let the blog being.  Its my intention to blog about applications that use SharpZipLib, new features, the demoapplications that ship, programming techniques used. Right now 0.85 has just been released which is good as it been a long time between ... [More] drinks and this fixes a few bugs and adds a couple of handy things Zip64 which allows very large archives to be created. Modifying of an existing archive via the ZipFile class. The next step is to take a quick breath and decide were to go next.  In the very short term there are a couple of fixes ups, CF has been busted for a while with regard to encryption, and there is a nasty little bug in the compression code for low compression levels which really needs to be nailed down as well. Were is the project going?  Well that is something to think about.  I am seriously thinking of adding strong encryption to Zip files as this would be useful for me.  This would tie in with fixing encryption for the Compact Framework as well, so there is some synergy there perhaps. But the big picture is not clear to me.  Were should the library be headed? Or more accurately what do users want?  The library is currently a somewhat polygot collection of tools and one thing to do would be to tidy the API up so there is more consistency across the entire tool set. There are many directions that the library could be extended. Please make your views known.   [Less]

The SharpServerTools component has moved on a bit: refactored to make each server tool an addin, and enable addins for each database server type support for Oracle and SQLServer both have table describe functionality - right click on a table and invoke 'Describe' opens a browser of the metadata for that table

The ResourceToolkit addin has been added to SharpDevelop 2.1 ("Serralongue") in revision 1866. It is intended to be used in development of localizable applications and helps the developer with managing string resources by providing tool tips on ... [More] resource keys and code completion. These features are currently working in most cases when the .NET framework resource accessing classes (System.Resources.ResourceManager or derived classes) are used. String resource access using ICSharpCode.Core ("${res:...}" or ResourceService.GetString) is also supported. The following screenshot shows the resource code completion window: The documentation of the previous (discontinued) stand-alone version of this addin is still available on my website: http://dev.hornung.dynalias.com/ There you can find some more detailed information especially on the exact coding requirements for the addin to detect the resource references. If you already had the stand-alone version installed, and are now upgrading to a newer SharpDevelop build, you should uninstall the stand-alone version using the AddIn Manager to avoid problems and duplicate menu items.   New features The integrated version of the addin has some new major features that were not present in any previous version. First, "Find references" and "Rename" commands are now available for resource keys:   They operate on the whole solution and can be used like the similar commands for classes, methods etc. "Rename" will rename all occurrences of the resource key in code, the resource key itself in the resource file and also in all localized resource files with the same name, as long as these are in the same directory as the main resource file. Two other new commands are available through the tools menu:   These commands also operate on the whole solution. Their performance is quite bad at the moment because they need to resolve all resource references in all source code files, but I have already some ideas how to improve that. "Find missing resource keys" looks for resource keys that are referenced in code but cannot be found in the resource file. The results are displayed in the search results panel: Here I ran this command on a copy of the SharpDevelop source code (this took about 72 seconds in debug mode, by the way). The one item it has found here is not actually a missing key. The addin has found the string "${res:" as an indication of an ICSharpCode.Core resource reference, but of course it cannot find this key because it is concatenated at runtime with a variable, and so this key is reported as missing.   "Find unused resource keys" looks for keys that are present in a resource file but not referenced anywhere in code. The results are displayed in a new view:   Here I ran this command on the SharpDevelop solution as well.Note that you have to be very careful with the list you get here. The addin cannot detect all kinds of resource references, especially not ones that are outside the scope of the open solution. So this list most probably always shows some keys that are in fact used somewhere. For example, all the "Templates." keys are listed here although they are used, because the are only referenced in the external template files which the addin knows nothing about. Because of this problem, I plan to add some filtering capabilities to this view so that you can filter out the "false positives" more easily. Resource keys can be deleted directly from this view by using the context menu or the delete button in the SharpDevelop toolbar after selecting one or more rows in the list. The keys are also deleted from the localized resource files if these are in the same directory as the main resource file.  [Less]

Support for a basic Code Navigation History has been added to SharpDevelop 2.1 as of revision 1569.  Built to enable "Navigate Back" and "Navigate Forward" with respect to major changes in cursor position, such as that resulting from a "Goto ... [More] Definition  Ctrl-Enter" command or jumping to the position of an Error in the Error log. This feature set is a work in progress; basic functionality is enabled but check the Known issues and Future improvement sections below before posting a Bug Report to the forums. Feature summary Two new toolbar buttons provide backwards & forwards navigation through visited positions in the editor windows; Navigating backwards & forwards resets the active file & cursor position to the specified point, effectively "undoing" major cursor position changes; When adding a cursor position to the history, recent similar cursor positions in the same method are removed; The NavigationService that lies underneath this feature set has been built for extensibility, delegating the management and navigation of cursor positions to individual IViewContent implementations.  This means that #develop developers can provide backwards/forwards functionality that is tailored to a specific view; for example: backwards/forwards in a source code file might refer to classes and methods visited rather than specific line numbers; backwards/forwards in Design view might refer to a list of controls selected while designing; backwards/forwards in an XML document might refer to nodes in a tree representation; At the moment, however, only navigation by filename and line number is supported.  Text file positions are considered the "same" if the difference in line numbers is less than 5, which helps weed out multiple consecutive positions travelled when scrolling via the cusor keys. Feature tour The toolbar buttons appear in the toolbar, disabled when the navigation history is empty: Navigation points are stored when significant changes are made to the cursor position, most notably via jumps such as using the "Goto Definition" command: Having clicked "Goto Definition" and jumped to a new position in the source code, notice that the "Navigate Back" button is enabled: We can now click on the "Navigate Back" button to return to the code position we just left: Now that we've gone back, notice that the "Navigate Forward" button is also enabled: Clicking the "Navigate Forward" button returns us forward along the code path to the cursor position from which we navigated back: Now that we have returned forward to the end of our history (the place where we first clicked "Navigate Back") the "Navigate Forward" button is disabled, as expected: Using the drop-down portion of the "Navigate Back" split button control, we can open a list of all cursor positions stored in our history.  This list is grouped by file (while only the name of each file appears at the top menu, sorting is done on complete file path): Pulling open each file name's submenu opens a list of positions in that file, each represented by the line number and a snip of text from that line: The last item in the "Navigate Back" drop-down menu allows you to empty the navigation history: And we see that both buttons are disabled, as expected: Technically, the history is not actually empty at this point, as the current cursor position is stored against the possiblity of future position changes.  The buttons are disabled because, although this current position is still stored, forwards and backwards are meaningless when only one position exists. Known issues  Navigation history is not stored between sessions - the navigation history is built from scratch on startup as previously open files are reopened; Navigation that involves opening a previously closed file tends to log an unintended "initial" file position (at line 1, column 1) in addition to the desired editor position; Going "forward" to the end of the navigation path correctly disables the "Navigate Forward" button, but going "backward" to the beginning of the path does not disable the "Navigate Back" button; at present this is by design to allow direct navigation to any stored point via the "Navigate Back" button's dropdown. Future improvements Filename changes and document operations (insertions/deletions) will be tracked and navigation points automatically updated accordingly; Class & method info will be stored alongside the filename and line number so that the dropdown menu can be organized by class as well as filename; When adding a cursor position to the history, all other cursor positions in the same method are removed. [Less]

Support for creating WiX setup packages is now available in SharpDevelop 2.1. It was originally disabled in SharpDevelop 2.0, but has now been re-enabled and some new features have been added. It is still a work in progress. ... [More] Some parts are not quite finished and there are some missing features, but it is currently being used to build and maintain the installer for SharpDevelop itself. At the moment SharpDevelop ships with WiX 2.0.4221, but it will be updated to 2.0.4415.0 shortly.FeaturesWiX project and file templates.Build a setup package (.msi), merge module (.msm) or WiX Library (.wixlib) from inside SharpDevelop. All built using MSBuild and WiX's custom MSBuild tasks.Add WiX libraries, WiX extensions and preprocessor variables to the WiX project.WiX Dialog Designer.Setup Dialogs window. Lists all dialogs in a project. Each dialog can then be opened up in the designer.Setup Files editor. Add directories, components and files to the installer via a GUI instead of editing the XML.The next sections will look at the WiX support in more detail.Creating a WiX ProjectTo create a new WiX project, from the File menu, select New and then select Solution.... In the New Project dialog select the Setup category.SharpDevelop has two WiX project templates available Empty Setup. This project template creates a Solution (.sln), a WiX Project (.wixproj) and a minimal WiX Setup file (.wxs). Setup. The Setup project template creates a basic WiX project which can be built immediately after creation.The installer created by this project installs a License.rtf file to the installation directory.The Setup project template also has its own dialogs which can be customised.The Setup project is the project we will be using in this walkthrough.BuildingBuilding the WiX project is done in the same way as for other projects in SharpDevelop from the build menu.Output messages from the WiX compiler and linker are displayed in the Output window and any errors are added to the Errors window.Creating a Merge Module or WiX LibraryBy default the project will build an MSI file. You can choose to create a merge module (.msm) or WiX Library (.wixlib) from the project options. Select the project in the Project Browser, then from the Project menu select Project Options.From the Application tab you can change the output type to msi, msm or wixlib.RunningTo run the installer, select Run from the Debug menu or press F5. The installer will then be built and run and you will see the first dialog of your installer.Adding a new WiX FileYou can either have one big WiX setup file (.wxs) or split the project up into several different files. The WiX MSBuild tasks will compile all the WiX files and link them all into one installer.To add a new WiX file, select the project in the Project Browser window, right click, select Add and then select New Item.... From the New File dialog selecting the Setup category will show you the WiX file templates.Adding WiX LibrariesTo add a wixlib to your project, select WiX Libraries in the Project Browser, right click and select Add WiX Library.This opens up the file dialog where you can browse to one or more wixlibs and add them to the project.Adding WiX ExtensionsWiX extensions can be added to the project in the Compiling, Library and Linking tabs available from the project options. The Compiling tab determines what extensions are passed to Candle the WiX compiler. The Linking tab determines what extensions get passed to Light the WiX linker. The Library tab determines what extensions get passed to Lit the Wix Library Tool. If you are creating a setup package (.msi) then typically you should put the extensions in the Compiling and Linking tab. If you are creating a WiX Library (.wixlib) then you need to put the extensions in the Library tab.The extensions can either be typed in directly into the Extensions text box, one per line, as shown above, or you can click the Add button to open the Add Extensions dialog and select one or more of the standard extensions WiX provides.Preprocessor VariablesPreprocessor variables can be added in the Preprocessing tab available from the project options.In the screenshot above the DATADIR variable is defined. Generally the variable values will just be strings, but you can also use MSBuild properties. In the screenshot above the SharpDevelopBinPath MSBuild property is being used. You can use MSBuild properties here since these properties will be expanded before WiX compiles anything.In the UserInterface.wxs file the DATADIR preprocessor variable is referenced as shown below:<Binary Id="dialog.bmp" SourceFile="$(var.DATADIR)/default-dialog.bmp" />Visually Designing a DialogTo open a setup dialog in the designer, open the WiX file, move the cursor so it is inside the dialog element, then click the Design tab.You can also open a dialog in the designer from the Setup Dialogs Window, which is described in the next section.You can have multiple dialogs defined in one WiX file or create one file per dialog, it is up to you. If you have multiple dialogs then you need to move the cursor inside the dialog element before you select the Design tab otherwise the designer will not know which dialog to load. If you have only one dialog element in the file then the cursor can be anywhere in the WiX document and does not need to be inside the dialog element.In the designer you can reposition, resize and remove existing controls. You can also add new WiX controls from the Setup Dialog Controls tab by dragging them to the dialog.At the moment not all the WiX controls are supported and WiX specific properties are not available in the properties window.Setup Dialogs WindowTo open the Setup Dialogs window, from the View menu select Setup and then select Dialogs.The Setup Dialogs window is then opened.This window lists all the dialogs available in the project. You can open a dialog into the designer by right clicking it and selecting Open. Or view its XML by selecting View Code.Visually Editing Directories, Components and FilesTo open the Setup Files Editor, from the View menu select Setup and then select Files.The Setup Files Editor will look at all the WiX files in the project for the TARGETDIR Directory element or the DirectoryRef element. Once this is found then it will show the directories, components and files that will be installed.The left hand side of the editor shows the files in a tree view. On the right hand side of the editor you can modify the properties of the currently selected item.You can add directories, files and components to your installer by right clicking a tree node, selecting Add and then choosing an item to add.Adding DirectoriesTo add a directory and all its contents recursively to your setup, select the tree node where you want your directory added to, then right click and select Add Directory.This opens the Browser for Folder dialog. Select the directory and then click OK to have that directory and all its contents added to the setup package. Every file added will have its own component.Future ImprovementsThe WiX integration is not completely finished. Here is a list of items that will hopefully be added at some point.Improve the WiX dialog designer. Add support for all the WiX controls.Improve the files editor.Drag and drop support.Directory vs installer diff. Shows missing and new files.Add support for WiX include files (.wxi).Add GUI Editors for:FeaturesPropertiesBinariesIconsSequencesError and UI Text.AlternativesThere are a few other applications and plug-ins available that can be used to create WiX installers instead of SharpDevelop. Here is a list of the ones I am aware of.VotiveVotive is a Visual Studio plug-in that you can use to create WiX setup packages from inside Visual Studio.Just a few days ago, September 15th, Justin Rockwood released Votive version 3, which supports Visual Studio 2005. It does not have a dialog designer, but that is on its list of features that will be added in the future.WiX EditWiX Edit is a standalone WiX Editor application, created by Jasper Keuper, that you can use to create WiX setup packages. It includes a dialog designer along with a whole host of other features, that SharpDevelop does not have. In fact you can create an installer and never look at any XML.WixTrimWixTrim is a WiX Visual Editor, created by Oleg Zelenkov, that supports a very advanced dialog designer amongst other features. The source code for the editor is also available from GotDotNet. Unfortunately, WixTrim is not under active development like the previous two.WiX TutorialIf you want to learn more about WiX then a fantastic WiX tutorial, created by Gabor Deak Jahn, is available online. [Less]