The first week of xRM Portals Community Edition has come and gone, and I’ve been thinking of some next steps to take with the project to make it useful and relevant to those who would like to use and/or contribute to it. GitHub has a projects feature where you can keep track of plans and tasks outside of issues, and I’ve added an initial first set of efforts I’d like to see happen.
The most up to date of items are on the projects page, and here is a copy of them with some additional thoughts on what they can each accomplish:
- Fix compilation warnings – The majority of issues created so far have to do with there being a few dozen C# compilation warnings when building the projects. For the most part these are benign, but they do result in unnecessary noise when viewing the build output. I suspect there may also be some bugs revealed through fixing them, in particular in issue Fix ‘warning CS0162: Unreachable code detected’ compilation warnings there is code where an errant return statement appears to be preventing further code from executing that should be.
- Update NuGet packages – Many of the NuGet packages being referenced are old versions that could potentially be updated to modernize the code base. This one isn’t too suprising to see, as it’s one of those efforts that easily arises when facing many other competing priorities.Each package will need to be inspected carefully to determine if it can be updated to a newer version and understand what the impact would be, as newer versions could introduce a variety of changes such as bug fixes, new features, or breaking changes. Ideally the functionality tied to each package would be sufficiently tested so that the impact of the update can be understood and any necessary changes implemented and tested. This could prove to be a large undertaking, but we won’t know until getting into the effort.
- Update .NET Framework – The projects are all targeting an older version of .NET Framework (4.5.2), this is another effort that could easily have been put to the wayside in liue of other competing priorities. I think this will probably be a small and low risk effort to complete, because newer .NET Framework versions are for the most part backwards compatible with earlier ones. The newest version as of today is 4.7. Updating to the newest version will give us the opportunity to modernize the code base and provide access to newer framework and language features. For example, the newest versions support higher versions of .NET Standard, giving access to newer libraries targeting that standard and features available in .NET Core.
- Add wiki documentation – There’s only so much information you’d want to include in the README file of a project, with the wiki being the perfect place to hold additional content that supplements the code. In the interest of time, the README so far only has some basic information about the project, deferring to a large part to content supplied by Microsoft on their download center. There is a lot more nformation to know and communicate about a project for it to run smoothly, independently, and be usable to users and contributors, such as contribution guidelines, coding standards, development environment setup instructions, testing procedures, installation and deployment procedures, versioning strategy, release notes, project roadmap, and so on. This will be a long running effort that never ends.
- Setup continuous builds – This one is partly inspired by GitHub suggesting this in every pull request because it isn’t already setup. Having continuous builds through AppVeyor or VSTS would assist in validating proposed code changes in pull requests compile successfully, so that the review process can focus more on the code and testing and less on the fact that the code compiles. A future endevour to this could expand into including automated test execution as well, although considering there weren’t any tests provided in the source code, this would be a long term goal which we could start with incremental efforts once continuous builds are in place.
- Create releases – Somewhat related to continuous builds, we should have versioned releases with precompiled assets so that installations can be performed without needing to compile from source. The barrier to entry will be much lower to new users if precompiled versions of the application are made available, and include non-developers as a target audience for who would be downloading and installing the project. From my own personal experience I’m much more likely to use an open source project if it has an installer or precompiled version that can be downloaded and installed. The infrastructure that creates the continuous builds should be able to also create versioned builds that are downloaded from the release page.
- Update SafeHtml to use only managed code – The SafeHtml project is using a native dll, osafehtm.dll, that could probably be replaced with a .NET equivalent lbrary for sanitizing HTML content. Any time there’s a native dll with pinvoke code in a .NET library, that’s a code smell that’s going to catch my attention. The use of the SafeHtml project is a little suprising to me because there was already HTML sanitization code in the Adxstudio Portals codebase prior to Microsoft taking over, so it’s possible there was some benefit to using the osafehtm.dll file or perhaps it was a simple case of not being aware of existing functionality and adding another library to accomplish the same task. Native dlls are sometimes used to improve performance in hot spots of code, however I highly doubt osafehtml.dll was used for performance reasons. I’m pretty sure we should be able to find a replacement .NET library that securely sanitizes HTML content, in fact I recall there being at least one .NET library from Microsoft in the past that did this.
- Replace all DllImport files with NuGet package references – Adxstudio Portals was started before the widespread adoption and acceptance of using NuGet for managing references to projects. The approach taken during this time to ensure developers could easily get the latest source code and compile it with all the dependent .NET libraries being available was to put the assemblies (dll files) in a folder called ‘DllImports’, that all projects would then reference for the assemblies they needed. While it seems that a majority of assembiles from the DllImports folder have since been replaced with NuGet package references, there are still a handful of assemblies still located in the DllImports folder that would ideally be deleted and all references to them replaced by NuGet packages. It could be that some of the assemblies in there don’t have NuGet packages available for them, which if it is the case is a tellling sign that the assembly is due to be replaced with a more modern equivalent.
I think it’s clear that there’s a lot of work to be done. The time it takes will depend on the amount of time and energy put into it. As a community-oriented project I’m hoping to see others outside of Adoxio contribute to this project so that it can move along at a decent pace. If you’re interested in contributing please consider taking on one of the issues we’ve tracked, or send us an email using the address shown at the top of our GitHub organization page.