On behalf of the entire Bridge.NET team, we’re excited to announce the official public release of Bridge 16.

This major version release represents a significant advancement in bridging C# applications into the browser.

The list of improvements in Bridge 16 spans all our projects and beyond, while including no less than 378 closed issues, with 87 new features being logged.

Let’s work our way through some key highlights from this release.

Newtonsoft.Json

Code reuse between Bridge apps and native C# apps is one of our foundational prime directives that we’re building towards, so supporting the same library API’s across both app environments is critical.

As .NET developers, including Newtonsoft.Json is one of those default actions we all do for new projects, and currently, with 77+ million downloads, it’s THE keystone library of the .NET universe.

We don’t want to eclipse our Bridge 16 release announcement, but we’re over-the-moon excited to be also launching our new Bridge.Newtonsoft.Json project.

The depth and breadth of features within the original Json.NET library is quite vast, but for the first release of Bridge.Newtonsoft.Json we needed to keep the scope contained, so we focused on supporting a strong core subset of features.

It only takes seconds to add Json.NET to your Bridge project by using the following command in your NuGet Package Manager Console:

> install-package bridge.newtonsoft.json

All features currently supported by Bridge are detailed within the README document of the GitHub repo.

For now, the core SerializeObject and DeserializeObject methods have received the most attention with related functionality for Formatting , JsonSerializerSettings , and the [JsonConstructor] Attribute also being included.

Everything is documented in the README and is the best place to start.

Example (Deck)

Work on the Bridge.Newtonsoft.Json project hasn’t slowed down one bit since this initial release, and support for another big batch of the API is expected soon.

Be sure to play around with Json.NET in Deck.NET. We’ve included a basic sample to help get you started.

C# Debugging in the Browser

Bridge 16 now includes support for debugging your C# files directly in the browser using source maps. Open any Deck to see source maps in action.

The following screencast demonstrates setting a breakpoint in the C# and watching a variable using Chrome Developer Tools.

Use F12 or Ctrl + Shift + I on Windows to open, or Cmd + Opt + I to open on a Mac.

Using the browsers developer tools to set breakpoints and the next time the breakpoint is hit (or page refreshed) the debugger will stop on the breakpoint.

Source maps can be enabled on a project by setting the sourceMap config in bridge.json.

{

"sourceMap": {

"enabled": true

}

}

Upgrading to Bridge 16

If you’re upgrading to Bridge 16 from an earlier release, be sure to review the Upgrading to Bridge v16 wiki document for tips on how to take advantage of the new features while also configuring for backwards compatibility.

The Backwards Compatibility Quickstart should help quickly get any existing project upgraded without making significant changes to the source code, structure, or functionality.

PRO TIP The wiki is editable, and please feel free to contribute.

[Convention] Attribute and Casing

Bridge 16 does introduce a Breaking Change from previous releases that is important to highlight.

The compiler will no longer automatically re-case member names.

For example, previously if you had a method in C# defined as DoSomething() , the compiler would emit doSomething() in the generated JavaScript.

Now, by default, Bridge will no longer re-case anything and it’s a What-You-See-Is-What-You-Get (WYSIWYG) policy.

If you’re upgrading from a previous release and would like to maintain the old naming convention policy, it’s very easy to revert back to the previous functionality.

Bridge can still change the case, but now must be explicitly enabled with the use of the powerful new [Convention] attribute. The [Convention] attribute can be configured at many points within your application, and setting at the Assembly level makes it easy to adjust the behaviour globally.

The following sample demonstrates configuring the compiler to convert all members (such as methods, properties, and fields) to use LowerCamelCase naming convention in the generated JavaScript.

[assembly: Convention(Target = ConventionTarget.Member, Notation = Notation.LowerCamelCase)]

See Issue #2477 for more information on the [Convention] attribute, or the Attribute Reference wiki documentation.

New Output path and MSBuild Macros

Previously Bridge placed the generated files into a /Bridge/output/ folder off the project root. This path was determined from the output config of the project’s bridge.json file.

In Bridge 16, the default output path has been updated to emit all project files into a new folder within your projects /bin/.

As an example, if you compile your Project in Debug mode, all output will be sent to the /bin/Debug/bridge/ folder. In Release mode, the output location would be /bin/Release/bridge/.

Example

This flexibility to target variable paths was made possible by our new support for MSBuild macros, such as $(OutDir) . The full list of token values available to use in bridge.json include the following:

$(AssemblyName)

$(CheckForOverflowUnderflow)

$(Configuration)

$(DefineConstants)

$(OutDir)

$(OutputPath)

$(OutputType)

$(Platform)

$(RootNamespace)

After compiling your project, you can locate the files by browsing through your File Explorer, or from within your Visual Studio project, click the Show All Files button then navigate through the folders.

The following screencast demonstrates how to compile your project, show the hidden files in your /bin/, and then open the index.html file in a browser.

Compile and show hidden files

If you’re upgrading an existing Bridge project to Bridge 16, the compiler will continue to use your previous output value, so everything should just continue to work as expected.

GitHub issue #2227 includes all the details regarding the new MSBuild macro support.

The NuGet installation process has also been significantly cleaned up, and now only one file (bridge.json) will be added to your project root folder.

Auto Index.html

As you might have caught from the video above, by default, Bridge now automatically generates a basic index.html file for your app. The file is included into the output folder alongside the JavaScript files.

After a successful compilation of your project, just open this new index.html in a browser and your app will load.

In the past we had included a static .html file to use as a template, but developers were required to manually add .js <script> files, which could easily lead to error if .js files were missed or included in the wrong order.

Now including everything you require to run your app is automated. Bridge figures out what you need, when you need it, and includes everything. Just compile, then view in a browser.

This new functionality can also be easily disabled with a config setting in your bridge.json.

{

"html": {

"disabled": true

}

}

The html config documentation lists all currently supported options. This is also a feature we’re expecting to expand in coming releases with new config options and greater templating flexibility.

Reflection Improvements

Reflection is now supported by default and a separate [app-name].meta.js file is created to host the reflection metadata.

Previously, Reflection was an opt-in decision that required adding [Reflectable] attributes without your source for configuration. The [Reflectable] attribute is still supported and functions the same, but they’re not required if you’re okay with the default functionality.

Reflection metadata can be disabled and much more customization is possible within bridge.json by setting the reflection config.

{

"reflection": {

"disabled": true

}

}

If you would prefer to revert back to the previous functionality of custom configuring your level of Reflection support using [Reflectable] attributes, which does allow for much more fine-grained control, just disable reflection in bridge.json and you’re good.

PRO TIP If you’re not using reflection within your project, disable reflection as the .meta.js files will grow in size proportionally to how big your project becomes. If you don’t need reflection, turn it off.

The new reflection functionality was implemented in GitHub issue #2732, which also contains additional tips on how to optimise metadata generation.

Bridge Console Refinements

We find the Bridge Console to be an indispensable tool for quickly logging results and debugging, and feedback from the community regarding Bridge Console has been overwhelmingly positive, but it was time for some polishing.

First up, the Console is now loaded from a separate bridge.console.js file, and can be easily removed from your project by either not including the .js file, or controlled with the new console config in bridge.json.

{

"console": {

"enabled": false|true

}

}

In previous versions, writing objects to the console would result in the useless [object Object] message. Writing objects of primitive types such as a string or bool worked fine, but we wanted better handling of complex objects.

Bridge Console usability has been significantly improved by first serializing the object to JSON before writing to the console. See demo at Deck.NET.