Archive for category Tools
BPMN question
Recently I learned how to model business processes with BPMN 2.0, the Business Process Modeling Notation. Following, a very, very brief introduction.
Using the BPM standard allows technical and business engineers (and everybody else) to better understand one another by using a process-oriented approach to modeling, while keeping the advantage of having executable (automatable) process models. It is highly recommendend to pre-define certain patterns and guidelines for usage, especially when working cross-departmental and cross-functional or rolling out company wide.
The great thing about BPMN is that it is really simple. This process obviously doesn’t do anything useful, it’s only to show some of the tasks, events etc.:
Now, a problem. Let’s say asynchronous service calls are modeled like like this:
How do you model synchronous service calls? You could do it like this:
But is that really 100% unambiguous? Sure, there would also be notes about the details (and objects used) of the process. But wouldn’t this be better?
There’s been quite some discussion about this; if anybody here has an opinion or best practise advice, let me know.
On merging project files
Merging Visual Studio Project files: there’s not much nice to say about that. It’s just a pain, and I’ve ssen it become the number one or two reason of errors when merging between code branches.
Even when a project consists of a single team, it is not unusual that one developer adds a bunch of files while another one adds some more, or deletes and moves things around in the project. The source control system and its diff/merge tooling easily copes with the added and deleted code files, and it reliably notices and auto-resolves changes within code. However, to integrate into Visual Studio and the build process, code files also need to be referenced correctly in the *.csproj (or *.vbproj) project files. Here, developers often find strange conflicts, and the diff/merge tools are often not much of a help.
Project files consist or XML that is read by Visual Studio and Msbuild. Their root element is a Project. Project has child elements that indicate properties of the project like its build configuration (and some more), but most important in this context are the ItemGroup elements that contains the content the project:
- Compile elements that define files compiled into the assembly
- Content elements that define files not compiled, but otherwise included in the project: MVC views, script files, images contained in a Silverlight XAP…
- Reference elements that define the projects binary or project dependencies.
Here’s a simplified project file for an ASP.NET MVC project file:
<Project>
<!-- Project properties and extensions omitted for brevity -->
<ItemGroup>
<Reference Include="System.Web.Mvc />
<Reference Include="System.Web.WebPages" />
</ItemGroup>
<ItemGroup>
<Compile Include="Controllers\SquirrelController.cs" />
<Compile Include="DataAccess\SquirrelRepository.cs" />
<Compile Include="Global.asax.cs">
<DependentUpon>Global.asax</DependentUpon>
</Compile>
<Content Include="Global.asax" />
<Content Include="Content\Site.css" />
<Content Include="Web.config" />
<Content Include="Web.Debug.config">
<DependentUpon>Web.config</DependentUpon>
</Content>
<Content Include="Web.Release.config">
<DependentUpon>Web.config</DependentUpon>
</Content>
<Content Include="Scripts\jquery-1.4.1.js" />
<Content Include="Scripts\jquery-1.4.1.min.js" />
</ItemGroup>
</Project>
Now why is there such a problem? First, most diff/merge tools just do not understand XML. These tools are designed to identify blocks of code. They know things about code: that outside strings, different kinds of whitespace can be considered as equivalent; that changes within a comment are less significant than elsewhere; where casing is significant or not. What most tools do not understand is that all of the following statements are equivalent:
<Squirrel name="Alex" fur="red"/>
<Squirrel fur="red" name="Alex" />
<Squirrel
fur="red"
name="Alex" />
<Squirrel fur="red" name="Alex"></Squirrel>
Secondly, the order of ItemGroup elements in the project, and of elements within them, does not matter – in programming languages, the sequence of statements is essential. Now that for project files the sequence is not significant, Visual Studio feels free to arrange items as it feels fit – and the diff/merge tool report hard to resolve conflicts even if two versions of a project file are absolutely equivalent.
Avoiding the pain
One feasible way of avoiding merging between versions of project files is to apply pessimistic locking. Only one developer can have a writable copy of the project, and there are no more conflicting version (at least within the same code branch). The downside is that developers may have to wait for their colleagues to finish their revision. The most frequent thing that a developer does with a project file is probably adding content. To get the shortest possible pessimistic lock on the project file, it should be committed as soon as the files are added – the added files should not contain any code at that point in time that could break the build until it is complete.
However, this approach does not remedy merges between code branches, and does not work with source control systems that just do not allow any pessimistic locking. And this includes each distributed source control system like Git or Mercurial.
Tooling
As we’ve seen, the root of the problem is not that project files are resistant to merging by their nature; it’s just the standard tooling that do not fit. However, there are specific tools that can help. The best candidate I’ve seen so far is a commercial yet relatively cheap (19€) tool called ProjectMerge (http://www.projectmerge.com). ProjectMerge understands XML: it recognizes equivalent XML elements and attributes despite or a possibly different serialization into text. But what is really sweet is that ProjectMerge can be told if the order of elements matters, and by which attributes equivalent elements are determined. In the case of Visual Studio project files, this attribute is the Include attribute of Compile, Content, None, and Reference elements. In effect, ProjectMerge will be able to understand these instructions are equivalent:
<Compile Include="1.cs" /> <Compile Include="2.cs" /> <Compile Include="3.cs" /> <!-- and --> <Compile Include="3.cs" /> <Compile Include="2.cs" /> <Compile Include="1.cs" />
The necessary settings to understand a specific project file format are stored in a distributable file format. Here’s my (probably not very complete) shot at C# projects – download here (from my Dropbox) and store under %PROGRAMDATA%\Oso\ProjectMerge\Formats.
I haven’t used the tool in practice yet, but I think we’re going to try it in a >10 person team over the next week, and see how it performs.
Updated: Syntax Highlighting for ScrewTurn Wiki
ScrewTurn Wiki is an excellent free wiki engine that I love and that I’ve written a source code syntax highlighter plugin for.
The plugin literally just hooks in the client-side SyntaxHighlighter by Alex Gorbatchev. Alex has published a new version some months ago. The version 3 has better support for copy&paste without the need for buttons in the toolbar, and some added elegance in its internal structure and extensibility. The new version of the plugin simply uses this version; there’s not much else to be said about it.
If you’re using the ScrewTurn wiki plugin with your own downloaded version of the SyntaxHighlighter, it’d be best to update to version 3 as well. You can use ScrewTurn’s auto-update functionality to obtain the new version of the plugin.
Links
Format all files in project
Yesterday I discovered an awesomely useful Visual Studio macro: it applies that code formatting rules to all files in the whole solutions. Code formatting includes indentation, spacing, tabs vs. spaces: all the things that people tend to get irate about. By default, these formatting rules are applied only when you write new code. To apply them to an existing page, there’s the command Edit --> Format Document with the keyboard chord Ctrl-K, Ctrl-D. Now this macro goes and opens all files and applies this command – a very good idea to do before a major commit.
Sub FormatProject()
For Each Proj As Project In DTE.Solution.Projects
For Each Item As ProjectItem In Proj.ProjectItems
Dim window As EnvDTE.Window
Try
window = Item.Open()
window.Activate()
DTE.ExecuteCommand("Edit.FormatDocument", "")
Catch ex As Exception
End Try
Next
Next
End Sub
Found as a comment by saraford to this MSDN post from 2005.
NDepend: My new hammer for code reviews
Welcome a new member in my toolbox: NDepend. If you haven’t seen it yet: it is a tool for static code analysis for .NET code – static code analysis meaning that it looks at a set of assemblies and source code and tries to figure out how it all hangs together, and tells you something about its inner characteristics. It can for example tell you which are the most referenced or the most complex classes in your project, and if the way that your project is really structured is similar to the way you think it is. NDepend also sports the most busy, dense, chaotic and against-any-expectation user interface that I have ever seen, and you too.
I have been using NDepend once in a while for some while, but more on an on and off basis. I basically used it as a means of due diligence on code that I do not know, but have to get my feet into. NDepend can give you an overview of the structure of a large piece of software, and some of its problems, in 15 minutes. Now, I found a reason to use it on an at least weekly basis.
I’m currently involved in a project where multiple SCRUM teams are working on the same code base. When a Sprint (that is a project step in a time box of four weeks, but you should really know that) ends, the team runs a demo with the product owner (“PO”), who decides if the result are acceptable. Each Sprint is on its own code line. Now after the PO gives her OK, the code can go to the MAIN code line: the content of the product that is going out to the customer (it’s not that simple, but you get the picture).
Now the PO does not really care about code quality, unit test coverage and quality, or the completeness of test plans. So before the code that comes out of a Sprint is released to MAIN, it is reviewed by an independent group of developers, and this is where I’m involved. Not all code from the Sprint is reviewed, about 10% are normally sufficient to see if a team has put enough emphasis on clean and structured work. But how do you find out what has been changed, and how do you pick the 10% that are most relevant?
The approach until now is to get the list of changed files from the source control system, and pick the files to review by making a guess. The problem is that the list of changed files does not tell you how much has changed – often, there has been just an adjustment in the code formatting or the correction of a typo that caused the checkin.
And this is where NDepend is hugely helpful. It can not only run an analysis on a single project, it can get you the difference between two analysis results. In order to determine what has changed in the Sprint, you run an analysis on the state of the MAIN code line, and take that as the baseline for a differential analysis of the Sprint code line. What you get immediately is a ranking of types and methods that have been added or changed, in the order of the magnitude of the change, across multiple assemblies. That alone make a huge difference in the quality of the code review, and the time you need to get there.
And that is only the start. The most powerful feature of NDepend is that you can run queries in a SQL-style lingo against the code analysis. This for example creates a warning when you’ve got methods with too many (logical) lines of code:
WARN IF Count > 0 IN SELECT TOP 10 METHODS WHERE NbLinesOfCode > 30 ORDER BY NbLinesOfCode DESC
NDepend comes with a good set of these predefined queries, and you can write your own. Let’s say we want to get the classes with little comments, but only in code that has been added or modified within the Sprint:
SELECT TOP 50 METHODS WHERE
(WasAdded OR CommentsWereChanged ) // Only modified and new
AND (
NbLinesOfCode > 20 // A lot of code
OR CyclomaticComplexity > 15 // A lot of paths
OR NbVariables > 8 // Many variables
)
AND !IsGeneratedByCompiler // Exclude anonymous types
ORDER BY NbLinesOfCode DESC
In addition, you can actively search for things that you do not wish to see, like
- References to MVVM ViewModels
- References on concrete classes rather than on interfaces
- FxCop suppression attributes
- Usage of NotImplementedException
- Low unit test coverage
The only real limitation I’ve ssen is that a query can either run against types, methods, namespaces, or fields, but not against a mixture. You can for example not search for property setters that do not use the PropertyChanged event in types that implement INotifyPropertyChanged.
NDepend is free for limited usage for evaluation, academic, and open source projects; for commercial projects or the full feature set you’ll have to buy reasonably priced licenses.
Oh yes, and: NDepend can be targeted at Silverlight 3 and Silverlight 4 as well as normal .NET code.
SQL code in ScrewTurn Wiki: a workaround
ScrewTurn Wiki is an excellent free wiki engine that I love and that I’ve written a source code syntax highlighter plugin for.
Now some people who want to use the syntax highlighter for examples of T-SQL (Microsoft SQL Server’s dialect of SQL) encounter formatting problems when their code includes some SQL Server built-in funtions that begin with “@@”, as seen here:
IF @@ROWCOUNT = 0 PRINT 'Warning: No rows were updated';
ScrewTurn wiki delimits source code by double “@” characters. This in an unusual enough sequence that it works most of the time. But when you see how the above SQL code looks like in ScrewTurn wiki markup, you’ll see the problem:
.... text before the code block .... @@ IF @@ROWCOUNT = 0 PRINT 'Warning: No rows were updated'; @@ .... text after the code block ....
ScrewTurn thinks the code block is over before “ROWCOUNT”, and that a new one begins before “…. text after”. Which makes it quite unusable for T-SQL code samples.
Now I’ve been using ScrewTurn for a while, and one thing I liked about the current version 3 was that it has a smaller set of different markup options. After all, wiki markup should primarily be easy to remember! In version 2, there were actually two ways of defining a code block: the syntax with the “@@” that’s now the only option documented for version 3, and one syntax that uses four squirly brackets, like so:
.... text before the code block ....
{{{{
IF @@ROWCOUNT = 0
PRINT 'Warning: No rows were updated';
}}}}
.... text after the code block ....
And guess what? That syntax still works. At least in the current version of ScrewTurn (3.0.2.509).
The four squirly brackets are not exactly equivalent to the “@@” markup; wiki markup inside the squirly code blocks are still interpreted. So to make the encoding waterproof, it’s best combined with the . The syntax highlighter plugin works with that kind of markup as well. So to get nicely formatted SQL code, I’d finally recommend this wiki markup:
.... text before the code block ....
{{{{<nowiki> sql
IF @@ROWCOUNT = 0
PRINT 'Warning: No rows were updated';
</nowiki>}}}}
.... text after the code block ....
Does this solve the problem? How would a more intuitive solution look like? Please drop a comment!
Visual Studio 2010 Express – No tests, please.
So Visual Studio 2010 has been released today. I recognize that .NET 4 is a great step forward, and Silverlight 4 just sounds sweet. But for people who are not provided with licenses by their employer, there’s quite a drawback.
The Standard edition has gone away. The previously cheapest edition of Visual Studio is no longer offered. With Visual Studio 2010, the lowest possible license is the Professional Edition which comes for $550 with a basic MSDN subscription for one year and $1,200 for a license with one year of a full MSDN subscription. Now if you’re an enthusiast or self-employed on the lower end of the food chain, this might be hefty price tag – and a significant increase compared to Visual Studio 2008 Standard (approx $280).
So at a first glance, moving away from the full versions of Visual Studio to the Express versions might sound tempting. You can have multiple Express Editions on the same machine (e.g. C# for Windows Services and Web Edition for ASP.NET and Silverlight), and the license does not prohibit commercial use.
However, there is one drawback that sounds like a massive deal breaker to me. Running Unit tests with Visual Studio 2010 is not (easily) possible.
Firstly, the integrated MSTest feature does not seem to be included. It’s not in the menu, and the ASP.NET MVC2 template comes without the test project it normally includes. Well, I could live with that, as I am a confession NUnit aficionado.
But: in Express Edition, you cannot attach the debugger to NUnit. The usual workflow is: start NUnit, attach the debugger to the NUnit process, debug your test. In Express Edition, the ability to attach the debugger to an exisiting process has been removed. And as plug-ins don’t work due to licensing restrictions in Express Edition, it’s not possible to retrofit the ability to run tests. (Visual NUnit for example won’t install.)
Steve Dunns has published a workaround for NUnit; it works by turning the unit test project into a command line application and bootstrap NUnit. That’s a nice trick and not the opposite of elegant, but far from ideal.
I’m not one who says everything should be free. Microsoft do not claim to offer a free full-blown development environment; that’s OK. But from all things that you can leave out: why does it have to be the all abilities to run unit tests? That seems like a strange signal towards the importance of quality.
Oh no, not again.
One should assume intelligent people learn from their mistakes. Nevertheless, there are these things you do for the umpth time, and you know you’ll do it again, no matter how hard you try. Put a red sock into the washing machine with the white shirts. Lending out books without noting down to whom.
My today’s ONNA was not shutting down Fiddler correctly. I was in a training with a new developer who was working in a VM on her notebook, and she complained that she could not connect to the local web server with the correct URL. http://localhost was working, but it did not help much because the application requires SSL. What followed were 35 minutes of wild guessing around DNS issues, duplicate machine names in the network (a common issue when you deploy a VM image to training participants: as soon as more than one person connects the VM to the LAN via a network bridge, the fun begins), and SSL certificates, but to no avail. Then I asked her to reboot; that has never done any harm.
Or has it? There were a lot of programs running, but everything was saved, so she immediately clicked “Force shutdown” to shorten the time Windows needs to close the open applications before shutting down. At this moment it dawned on me that I had fallen for my ONNA No.2: Killing Fiddler.
Fiddler intercepts the HTTP traffic between a browser and a web server by acting as a proxy. When Fiddler is started, it registers itself into the WININET connection configurations – to see what this means, go to the connection options in Internet Explorer. All traffic to any web server is routed through the proxy, i.e. Fiddler. the local traffic (the one that goes to localhost) is excluded from this rule.
Now when Fiddler is shut down, it de-registers itself as the proxy and restores the original settings. Except of course when you kill the process, e.g. by a forced shutdown. In that case, all traffic is still sent to Fiddler, except of course that it is no longer there to pass it on. No server is reachable in that situation, except localhost. All the restarting of browser, web servers, and machines does not help until you either manually fix the proxy configuration or start and then properly shut down Fiddler.
I’ve been there. For many, many times in years. Hours that you’ll never get back. But if I can’t connect to the the local web server all at sudden next week…
I bet I’m going to reboot, debug, and swear.
P.S. My ONNA No.1 is having an NUnit project that runs against the Debug configuration of a C# project, and fixing a failing test. Visual Studio of course compiles into Release configuration. And I’m sitting there wondering why the damn test does not pass, whatever I do.
P.P.S. Please congratulate me to a new notebook: I’m getting a Dell 6510 Quad-Core from The Friendly Employer.
Prezi and Me
Last weekend, after successfully procrastinating the preparation of slides for a 4 hour training session next Wednesday, I really needed to get going. And since I did not bring my company computer home, and don’t have MS Office on my private one*, I had an excellent excuse to try something new, and so I signed up for Prezi.
Prezi displays one infinitely large canvas where you can place your presentation elements on, and then navigate through the presentation by zooming in and out, and moving around on it. Compared to the linear structure of as classical slide show, this lets you freely break out of the sequence if you feel like it. This looks like a real problem-solver to me – I repeatedly find myself shuffling through slide decks in order to go back to a already shown slide to answer a question, or worse, peek into a code sample five slides ahead to explain something. What you can do in the same situation with Prezi is zoom out until you see the code sample, zoom in to it, and then go back to where you’ve been – and it looks like an organic part of the presentation, not an accident.
Another thing that I love about Prezi is that since it supports precise scaling and rotating of text, you can do great things with typography. Here’s a chart that I’ve done (it is an affirming version of the number of open defects in a project that did not have QA resources): http://prezi.com/mlrgvrwb5oea/
When presenting, you can either freely move around, or follow a defined path. Or both. The path consists of frames that you put around elements you want to appear as a unit, and then you arrange an order between these frames. The transitions between frames look extremely dynamic and smooth: a LOT better than what you can do with PowerPoint. Yep, the effect is going to wear out once an audience gets used to it. But until then, you can really make an impression and stand out.
OK, that was how far the unmitigated love relation to Prezi went. As in most relationships, there are some hardships to endure.
The first one came right after the start: although it looks like Prezi had a classical “Freemium” revenue model that lets you try a reasonable amount of their functionality until you’re so convinced of a service’s value that you just _love_ to contribute some money, Prezi puts a very crucial feature behind the paywall: control over your content. In the free version of the service, all your presentations are public, full stop. For 60$/year, you get the ability to create private presentations, or to share them with a defined group of people. Outside the academic world, most presentations will however strictly be nonpublic, I suppose. Even if the content is not a secret in any way, the presenter will want to have an advantage over the audience in order to build suspense and channel the exposure of information. You don’t want an audience where half the people bore out because they’ve already seen it all. So for a trial with serious content, you have to have a payed subscription. On the other hand, the first month is free.
The other issue I have with Prezi is that it has an overly strong opinion about pureness of style. For each text block, there is a choice between three different style, two of them are named “Title” and one “Body”. These styles differ mainly by their color. For the presentation’s style, there is a selection of eight predefined styled that define font, background and text colors. You can not apply your personal or corporate branding, or even just have a text block in a monospace font (duh. Code samples.) There are hints in the community forum that a style editor is being developed, but today, the statement is that if you need a customized style, you need to commission Prezi to build one, for an unspecified amount of money.
And finally, I’d really like some more shapes. Prezi, you can draw arrows, but that’s it. I’m not asking for clip art (I am really not asking for clip art. I never use any.), but I’d really appreciate a rectangle, ellipse, or line. Pretty please? It would make drawing simple diagrams a lot easier.
In the community forum you can pick up that there’s a design process is going on on how feature-rich vs. pure Prezi should be. A really important point in the discussion is that the anti-patterns of PowerPoint are to be prevented. My two cents on the questions is that a) people without some talent are going to discover anti-patterns in anything anyway and b) that making Prezi somewhat more productive would not hurt anyone.
Anyway, I’m very much looking forward to presenting my session on next Wednesday.
* I do have OpenOffice, and I’m perfectly satisfied with it; especially with Writer. It’s like WinWord 2, which IMO was the best version of Word ever. But the PowerPoint derivate Impress does not grow on me; it feels clunky to me, repeatedly gets the bullet points and indentation wrong, and the results just don’t look that good.
Yet another syntax highlighter for ScrewTurn Wiki
ScrewTurn Wiki is an excellent free wiki engine. It’s open source, runs on top of ASP.NET, supports ActiveDirectory authentication, and is super-easy to set up. Because of these qualities, I use it as the default choice for product or project related internal wikis (and yes, you can of course run it on the Internet).
What ScrewTurn does not supply out of the box is syntax highlighting for source code. What it does have however is a well-documented and simple enough plugin model that allows you to roll your own. There already is a an implementation by Tim Bellette that is contained in a single DLL and looks very OK, and another one that uses the GeShi PHP application, which is good because GeShi knows every language in the world, but requires you to set up a PHP application in addition to ScrewTurn, which might be a problem or not.
Why I choose to come up with my own syntax highlighter plugin is that a) I sometimes like building stuff and need an excuse for that and b) I really like the source code formatter that WordPress uses. As you can behold it here:
// See how nice this looks? It's got line numbers, // alternating background, and these super-useful buttons // to copy the whole code into the clipboard and print it // that appear when you hover over the code.
The amazing thing about this formatter is that it is completely implemented as client-side JavaScript and CSS. Alex Gorbatchev has developed this little feat, and published it as open source. What you need to do to get code formatting onto an HTML page is to decorate a “pre” tag with a CSS class, and add links to the script files.
Letting ScrewTurn Wiki so this is quite easy. All you need to do is to write a formatter plugin. In addition to some minor infrastructure wire-up, this type of plugin lets you modify the content of a wiki article, and its title. The API for writing ScrewTurn Wiki is extremely enjoyable and well documented, deploying is a matter of seconds – you can just drop your DLL into the public/plugins directory of the web application, or even use its administrative user interface to upload new plugins into the app when you don’t have access to the server.
Usage
The markup for code in ScrewTurn Wiki is:
Text before the code @@ // Your source code goes here @@ Text after the code
In order to support wikis that already contain code following that syntax (and especially for one large project with 500+ pages…) this syntax is supported. However, it does not indicate which language the code is in, so that the formatter defaults to plain text; it still provides the line numbers and fancy background.
To indicate the language, add the name of the programming language as the first word of the code block. The name of the language can be any of the syntaxes supported by the SyntaxHighlighter. A single page in the wiki can contain code blocks in several programming languages.
@@ csharp // Comment public string Greeting = "huhu"; @@ Text between code blocks @@ xml <!-- Comment --> <node&gt;content</node&gt; @@
Configuration
In the admin UI of ScrewTurn Wiki, you can provide a configuration string for plugins. This one supports three configuration options:
- ScriptUrl The syntax highlighter needs to download some CSS, JavaScript, and Flash files. By default, these files are downloaded from my Dropbox (which makes quite a good poor man’s CDN). If you like to download them from somewhere else, specify the base URL in the ScriptUrl option. The best-performing way to deliver the files will be to download them onto the wiki’s web server and reference them with a relative URL.
- Theme The syntax highlighter offers some color-scheme themes. Pick one with this option; or omit it to use the default one.
- DefaultLang If no language is specified on a code block, the default language is used. Without specifying this option, no specific language is used and the code appears as plain text; specify the DefaultLang option to use another language as default.
In this example the script files are loaded from a directory on the wiki server with the machine-absolute URL “/syntaxHighlighter/”, the white-on-black Emacs color theme is used, and the default language is C#.ScriptUrl=/syntaxHighlighter/; Theme=Emacs; DefaultLang=csharp
- CustomLang
The syntax highlighter allows adding new javascript “brush” files in orde to support additional languages that are not included in the standard script library. *If you have not written or imported custom brush definitions, or if you don’t know what is meant by that, you do not need to set this option.*By default, the ScrewTurn plugin does not know about these custom languages. To use additional brush definitions, add a custom language to the configuration string, and add the name of the javascript file that implements it.
In this example, an additional language called “magic” is added. It uses a brush file named “shBrushMagic.js”.
CustomLang:magic=shBrushMagic.js
Note that the custom brush file has to reside in the same directory as the standard brush definition files.
You can specify multiple custom languages, and you can assign different synonyms for the same brush:
CustomLang:magic=shBrushMagic.js; CustomLang:mushroom=shBrushMagic.js; CustomLang:slippers=shBrushSlippers.js
Revisions
- 1.0 Initial Release. Uses SyntaxHighlighter 2.1
- 1.1 Uses SyntaxHightlighter 3.0
Download
DOWNLOAD SINGLE DLL
Installation: Download. Log onto ScrewTurn Wiki as an admin. Go to Administration -> Providers. Under “Providers DLLs Management”, upload the DLL: done.
SOURCE CODE
C#, Visual Studio 2010 Project – Hosted on Google Code
Licensed under LGPLv3 .
Known Issues
If you’ve got a problem installing the plug-in, or it does not work as expected, please use the Google Code issue tracking system. You’ll need to log on using a Google account.
Code blocks in tables
When you try to put a code block into a table, you’ll find out that this block won’t be formatted correctly. This is not a genuine problem of this plug-in, but caused by a general limitation in ScrewTurn wiki that does not allow any formatting in table cells. The FormatterPlus plug-in by Denis Stankovski fixes this. Together with this plug-in, code blocks in tables work fine.
-
You are currently browsing the archives for the Tools category.
Authors
-
