Please also see the full list of breaking changes in ASP.NET Core 3.0.
To upgrade an existing ASP.NET Core 3.0 Preview 7 project to Preview 8:
Update Microsoft.AspNetCore.* package references to 3.0.0-preview8.19405.7.
In Razor components rename OnInit to OnInitialized and OnInitAsync to OnInitializedAsync.
In Blazor apps, update Razor component parameters to be public, as non-public component parameters now result in an error.
In Blazor WebAssembly apps that make use of the HttpClient JSON helpers, add a package reference to Microsoft.AspNetCore.Blazor.HttpClient.
On Blazor form components remove use of Id and Class parameters and instead use the HTML id and class attributes.
Rename ElementRef to ElementReference.
Remove backing field declarations when using @ref or specify the @ref:suppressField parameter to suppress automatic backing field generation.
Update calls to ComponentBase.Invoke to call ComponentBase.InvokeAsync.
Update uses of ParameterCollection to use ParameterView.
Update uses of IComponent.Configure to use IComponent.Attach.
Remove use of namespace Microsoft.AspNetCore.Components.Layouts.
You should hopefully now be all set to use .NET Core 3.0 Preview 8.
Project template updates
Cleaned up top-level templates in Visual Studio
Top level ASP.NET Core project templates in the “Create a new project” dialog in Visual Studio no longer appear duplicated in the “Create a new ASP.NET Core web application” dialog. The following ASP.NET Core templates now only appear in the “Create a new project” dialog:
Razor Class Library
Blazor App
Worker Service
gRPC Service
Angular template updated to Angular 8
The Angular template for ASP.NET Core 3.0 has now been updated to use Angular 8.
Blazor templates renamed and simplified
We’ve updated the Blazor templates to use a consistent naming style and to simplify the number of templates:
The “Blazor (server-side)” template is now called “Blazor Server App”. Use blazorserver to create a Blazor Server app from the command-line.
The “Blazor” template is now called “Blazor WebAssembly App”. Use blazorwasm to create a Blazor WebAssembly app from the command-line.
To create an ASP.NET Core hosted Blazor WebAssembly app, select the “ASP.NET Core hosted” option in Visual Studio, or pass the --hosted on the command-line
dotnet new blazorwasm --hosted
Razor Class Library template replaces the Blazor Class Library template
The Razor Class Library template is now setup for Razor component development by default and the Blazor Class Library template has been removed. New Razor Class Library projects target .NET Standard so they can be used from both Blazor Server and Blazor WebAssembly apps. To create a new Razor Class Library template that targets .NET Core and supports Pages and Views instead, select the “Support pages and views” option in Visual Studio, or pass the --support-pages-and-views option on the command-line.
dotnet new razorclasslib --support-pages-and-views
Case-sensitive component binding
Components in .razor files are now case-sensitive. This enables some useful new scenarios and improves diagnostics from the Razor compiler.
For example, the Counter has a button for incrementing the count that is styled as a primary button. What if we wanted a Button component that is styled as a primary button by default? Creating a component named Button in previous Blazor releases was problematic because it clashed with the button HTML element, but now that component matching is case-sensitive we can create our Button component and use it in Counter without issue.
Notice that the Button component is pascal cased, which is the typical style for .NET types. If we instead try to name our component button we get a warning that components cannot start with a lowercase letter due to the potential conflicts with HTML elements.
We can move the Button component into a Razor Class Library so that it can be reused in other projects. We can then reference the Razor Class Library from our web app. The Button component will now have the default namespace of the Razor Class Library. The Razor compiler will resolve components based on the in scope namespaces. If we try to use our Button component without adding a using statement for the requisite namespace, we now get a useful error message at build time.
NavLink component updated to handle additional attributes
The built-in NavLink component now supports passing through additional attributes to the rendered anchor tag. Previously NavLink had specific support for the href and class attributes, but now you can specify any additional attribute you’d like. For example, you can specify the anchor target like this:
Improved reconnection logic for Blazor Server apps
Blazor Server apps require a live connection to the server in order to function. If the connection or the server-side state associated with it is lost, then the the client will be unable to function. Blazor Server apps will attempt to reconnect to the server in the event of an intermittent connection loss and this logic has been made more robust in this release. If the reconnection attempts fail before the network connection can be reestablished, then the user can still attempt to retry the connection manually by clicking the provided “Retry” button.
However, if the server-side state associated with the connect was also lost (e.g. the server was restarted) then clients will still be unable to connect. A common situation where this occurs is during development in Visual Studio. Visual Studio will watch the project for file changes and then rebuild and restart the app as changes occur. When this happens the server-side state associated with any connected clients is lost, so any attempt to reconnect with that state will fail. The only option is to reload the app and establish a new connection.
New in this release, the app will now also suggest that the user reload the browser when the connection is lost and reconnection fails.
Culture aware data binding
Data-binding support (@bind) for <input> elements is now culture-aware. Data bound values will be formatted for display and parsed using the current culture as specified by the System.Globalization.CultureInfo.CurrentCulture property. This means that @bind will work correctly when the user’s desired culture has been set as the current culture, which is typically done using the ASP.NET Core localization middleware (see Localization).
You can also manually specify the culture to use for data binding using the new @bind:culture parameter, where the value of the parameter is a CultureInfo instance. For example, to bind using the invariant culture:
The <input type="number" /> and <input type="date" /> field types will by default use CultureInfo.InvariantCulture and the formatting rules appropriate for these field types in the browser. These field types cannot contain free-form text and have a look and feel that is controller by the browser.
Other field types with specific formatting requirements include datetime-local, month, and week. These field types are not supported by Blazor at the time of writing because they are not supported by all major browsers.
Data binding now also includes support for binding to DateTime?, DateTimeOffset, and DateTimeOffset?.
Automatic generation of backing fields for @ref
The Razor compiler will now automatically generate a backing field for both element and component references when using @ref. You no longer need to define these fields manually:
<button @ref="myButton" @onclick="OnClicked">Click me</button> <Counter @ref="myCounter" IncrementAmount="10" /> @code { void OnClicked() => Console.WriteLine($"I have a {myButton} and myCounter.IncrementAmount={myCounter.IncrementAmount}");
}
In some cases you may still want to manually create the backing field. For example, declaring the backing field manually is required when referencing generic components. To suppress backing field generation specify the @ref:suppressField parameter.
Razor Pages support for @attribute
Razor Pages now support the new @attribute directive for adding attributes to the generate page class.
For example, you can now specify that a page requires authorization like this:
@page
@attribute [Microsoft.AspNetCore.Authorization.Authorize] <h1>Authorized users only!<h1> <p>Hello @User.Identity.Name. You are authorized!</p>
New networking primitives for non-HTTP Servers
As part of the effort to decouple the components of Kestrel, we are introducing new networking primitives allowing you to add support for non-HTTP protocols.
You can bind to an endpoint (System.Net.EndPoint) by calling Bind on an IConnectionListenerFactory. This returns a IConnectionListener which can be used to accept new connections. Calling AcceptAsync returns a ConnectionContext with details on the connection. A ConnectionContext is similar to HttpContext except it represents a connection instead of an HTTP request and response.
The example below show a simple TCP Echo server hosted in a BackgroundService built using these new primitives.
public class TcpEchoServer : BackgroundService
{ private readonly ILogger<TcpEchoServer> _logger; private readonly IConnectionListenerFactory _factory; private IConnectionListener _listener; public TcpEchoServer(ILogger<TcpEchoServer> logger, IConnectionListenerFactory factory) { _logger = logger; _factory = factory; } protected override async Task ExecuteAsync(CancellationToken stoppingToken) { _listener = await _factory.BindAsync(new IPEndPoint(IPAddress.Loopback, 6000), stoppingToken); while (true) { var connection = await _listener.AcceptAsync(stoppingToken); // AcceptAsync will return null upon disposing the listener if (connection == null) { break; } // In an actual server, ensure all accepted connections are disposed prior to completing _ = Echo(connection, stoppingToken); } } public override async Task StopAsync(CancellationToken cancellationToken) { await _listener.DisposeAsync(); } private async Task Echo(ConnectionContext connection, CancellationToken stoppingToken) { try { var input = connection.Transport.Input; var output = connection.Transport.Output; await input.CopyToAsync(output, stoppingToken); } catch (OperationCanceledException) { _logger.LogInformation("Connection {ConnectionId} cancelled due to server shutdown", connection.ConnectionId); } catch (Exception e) { _logger.LogError(e, "Connection {ConnectionId} threw an exception", connection.ConnectionId); } finally { await connection.DisposeAsync(); _logger.LogInformation("Connection {ConnectionId} disconnected", connection.ConnectionId); } }
}
Unix domain socket support for the Kestrel Sockets transport
We’ve updated the default sockets transport in Kestrel to add support Unix domain sockets (on Linux, macOS, and Windows 10, version 1803 and newer). To bind to a Unix socket, you can call the ListenUnixSocket() method on KestrelServerOptions.
In preview8, we’ve added support for CallCredentials allowing for interoperability with existing libraries like Grpc.Auth that rely on CallCredentials.
Diagnostics improvements for gRPC
Support for Activity
The gRPC client and server use Activities to annotate inbound/outbound requests with baggage containing information about the current RPC operation. This information can be accessed by telemetry frameworks for distributed tracing and by logging frameworks.
EventCounters
The newly introduced Grpc.AspNetCore.Server and Grpc.Net.Client providers now emit the following event counters:
total-calls
current-calls
calls-failed
calls-deadline-exceeded
messages-sent
messages-received
calls-unimplemented
You can use the dotnet counters global tool to view the metrics emitted.
We’ve added support in Visual Studio that makes it easier to manage references to other Protocol Buffers documents and Open API documents.
When pointed at OpenAPI documents, the ServiceReference experience in Visual Studio can generated typed C#/TypeScript clients using NSwag.
When pointed at Protocol Buffer (.proto) files, the ServiceReference experience will Visual Studio can generate gRPC service stubs, gRPC clients, or message types using the Grpc.Tools package.
SignalR User Survey
We’re interested in how you use SignalR and the Azure SignalR Service, and your opinions on SignalR features. To that end, we’ve created a survey we’d like to invite any SignalR customer to complete. If you’re interested in talking to one of the engineers from the SignalR team about your ideas or feedback, we’ve provided an opportunity to enter your contact information in the survey, but that information is not required. Help us plan the next wave of SignalR features by providing your feedback in the survey.
Give feedback
We hope you enjoy the new features in this preview release of ASP.NET Core and Blazor! Please let us know what you think by filing issues on GitHub.
Leaked Apple document says new Siri device is coming by fall 2021
By Malcolm Owen Friday, September 06, 2019, 06:13 am PT (09:13 am ET)
Leaked documents relating to Siri reveal upgrades to the digital assistant are coming in late 2021, aimed at supporting a new piece of hardware.
A list of Siri upgrades expected to arrive before “fall 2021” includes expected elements for “new hardware support” for a “new device,” though a report published on Friday is light on those details. Codenamed “Yukon,” the upgrades to Siri will introduce support for Find my Friends to the voice-based service, the documents claim. Siri will also include support for accessing the App Store, though the capabilities relating to that are not advised by a report.
Built-in machine translation could enable language interpreting capabilities within Siri, without needing a cellular or other network connection at all, a feature that could be handy for travelers.
A large section of the internal documents, provided to The Guardian by a former Siri “grader,” mentions how Siri could work with other devices in a variety of ways. At its simplest, features to enable Siri to read out message notifications to users wearing AirPods is suggested, while the ability to use Shazam via Siri on Apple Watch is also touted.
A bigger feature could be commanding Siri on one device to perform actions on another. One example given is to “Play Taylor Swift on my HomePod,” which could be said on an Apple Watch or iPhone remotely and interpreted to control the user’s smart speaker at home.
Arguably the biggest element is the ability to “have a back-and-forth conversation about health problems” with Siri. While this could take the form of Siri providing a basic diagnosis of the user to see if medical treatment is worth attaining, it is also possible that the conversations could form part of HealthKit or ResearchKit, Apple’s initiatives in the medical field.
Despite the lack of information relating to what kind of new Siri-equipped devices are on the way, one of the most likely candidates is the HomePod, which is enjoying success in reaching markets like China where rival systems from Google and Amazon aren’t available. It is plausible that Apple could produce a “mini” version of the HomePod, offering consumers a cheaper and smaller version in a similar vein to the Google Home Mini and the Amazon Echo Dot.
Apple has been rumored to be working on a new generation of the audio device for some time, with a cheaper variant also predicted by analyst Ming-Chi Kuo in April 2018, though such a model has yet to be launched.
In the previous article on RPM package building, you saw that source RPMS include the source code of the software, along with a “spec” file. This post digs into the spec file, which contains instructions on how to build the RPM. Again, this article uses fpaste as an example.
Understanding the source code
Before you can start writing a spec file, you need to have some idea of the software that you’re looking to package. Here, you’re looking at fpaste, a very simple piece of software. It is written in Python, and is a one file script. When a new version is released, it’s provided here on Pagure: https://pagure.io/releases/fpaste/fpaste-0.3.9.2.tar.gz
The current version, as the archive shows, is 0.3.9.2. Download it so you can see what’s in the archive:
fpaste.py: which should go be installed to /usr/bin/.
docs/man/en/fpaste.1: the manual, which should go to /usr/share/man/man1/.
COPYING: the license text, which should go to /usr/share/license/fpaste/.
README.rst, TODO: miscellaneous documentation that goes to /usr/share/doc/fpaste.
Where these files are installed depends on the Filesystem Hierarchy Standard. To learn more about it, you can either read here: http://www.pathname.com/fhs/ or look at the man page on your Fedora system:
Name: fpaste
Version: 0.3.9.2
Release: 3%{?dist}
Summary: A simple tool for pasting info onto sticky notes instances
BuildArch: noarch
License: GPLv3+
URL: https://pagure.io/fpaste
Source0: https://pagure.io/releases/fpaste/fpaste-0.3.9.2.tar.gz Requires: python3 %description
It is often useful to be able to easily paste text to the Fedora
Pastebin at http://paste.fedoraproject.org and this simple script
will do that and return the resulting URL so that people may
examine the output. This can hopefully help folks who are for
some reason stuck without X, working remotely, or any other
reason they may be unable to paste something into the pastebin
Name, Version, and so on are called tags, and are defined in RPM. This means you can’t just make up tags. RPM won’t understand them if you do! The tags to keep an eye out for are:
Source0: tells RPM where the source archive for this software is located.
Requires: lists run-time dependencies for the software. RPM can automatically detect quite a few of these, but in some cases they must be mentioned manually. A run-time dependency is a capability (often a package) that must be on the system for this package to function. This is how dnf detects whether it needs to pull in other packages when you install this package.
BuildRequires: lists the build-time dependencies for this software. These must generally be determined manually and added to the spec file.
BuildArch: the computer architectures that this software is being built for. If this tag is left out, the software will be built for all supported architectures. The value noarch means the software is architecture independent (like fpaste, which is written purely in Python).
This section provides general information about fpaste: what it is, which version is being made into an RPM, its license, and so on. If you have fpaste installed, and look at its metadata, you can see this information included in the RPM:
$ sudo dnf install fpaste
$ rpm -qi fpaste
Name : fpaste
Version : 0.3.9.2
Release : 2.fc30
...
RPM adds a few extra tags automatically that represent things that it knows.
At this point, we have the general information about the software that we’re building an RPM for. Next, we start telling RPM what to do.
Part 2: Preparing for the build
The next part of the spec is the preparation section, denoted by %prep:
%prep
%autosetup
For fpaste, the only command here is %autosetup. This simply extracts the tar archive into a new folder and keeps it ready for the next section where we build it. You can do more here, like apply patches, modify files for different purposes, and so on. If you did look at the contents of the source rpm for Python, you would have seen lots of patches there. These are all applied in this section.
Typically anything in a spec file with the % prefix is a macro or label that RPM interprets in a special way. Often these will appear with curly braces, such as %{example}.
Part 3: Building the software
The next section is where the software is built, denoted by “%build”. Now, since fpaste is a simple, pure Python script, it doesn’t need to be built. So, here we get:
%build
#nothing required
Generally, though, you’d have build commands here, like:
configure; make
The build section is often the hardest section of the spec, because this is where the software is being built from source. This requires you to know what build system the tool is using, which could be one of many: Autotools, CMake, Meson, Setuptools (for Python) and so on. Each has its own commands and style. You need to know these well enough to get the software to build correctly.
Part 4: Installing the files
Once the software is built, it needs to be installed in the %install section:
%install
mkdir -p %{buildroot}%{_bindir}
make install BINDIR=%{buildroot}%{_bindir} MANDIR=%{buildroot}%{_mandir}
RPM doesn’t tinker with your system files when building RPMs. It’s far too risky to add, remove, or modify files to a working installation. What if something breaks? So, instead RPM creates an artificial file system and works there. This is referred to as the buildroot. So, here in the buildroot, we create /usr/bin, represented by the macro %{_bindir}, and then install the files to it using the provided Makefile.
At this point, we have a built version of fpaste installed in our artificial buildroot.
Part 5: Listing all files to be included in the RPM
The last section of the spec file is the files section, %files. This is where we tell RPM what files to include in the archive it creates from this spec file. The fpaste file section is quite simple:
%files
%{_bindir}/%{name}
%doc README.rst TODO
%{_mandir}/man1/%{name}.1.gz
%license COPYING
Notice how, here, we do not specify the buildroot. All of these paths are relative to it. The %doc and %license commands simply do a little more—they create the required folders and remember that these files must go there.
RPM is quite smart. If you’ve installed files in the %install section, but not listed them, it’ll tell you this, for example.
Part 6: Document all changes in the change log
Fedora is a community based project. Lots of contributors maintain and co-maintain packages. So it is imperative that there’s no confusion about what changes have been made to a package. To ensure this, the spec file contains the last section, the Changelog, %changelog:
There must be a changelog entry for every change to the spec file. As you see here, while I’ve updated the spec as the maintainer, others have too. Having the changes documented clearly helps everyone know what the current status of the spec is. For all packages installed on your system, you can use rpm to see their changelogs:
$ rpm -q --changelog fpaste
Building the RPM
Now we are ready to build the RPM. If you want to follow along and run the commands below, please ensure that you followed the steps in the previous post to set your system up for building RPMs.
We place the fpaste spec file in ~/rpmbuild/SPECS, the source code archive in ~/rpmbuild/SOURCES/ and can now create the source RPM:
$ ls ~/rpmbuild/SRPMS/fpaste*
/home/asinha/rpmbuild/SRPMS/fpaste-0.3.9.2-3.fc30.src.rpm $ rpm -qpl ~/rpmbuild/SRPMS/fpaste-0.3.9.2-3.fc30.src.rpm
fpaste-0.3.9.2.tar.gz
fpaste.spec
There we are — the source rpm has been built. Let’s build both the source and binary rpm together:
$ cd ~/rpmbuild/SPECS
$ rpmbuild -ba fpaste.spec
..
..
..
RPM will show you the complete build output, with details on what it is doing in each section that we saw before. This “build log” is extremely important. When builds do not go as expected, we packagers spend lots of time going through them, tracing the complete build path to see what went wrong.
That’s it really! Your ready-to-install RPMs are where they should be:
$ ls ~/rpmbuild/RPMS/noarch/
fpaste-0.3.9.2-3.fc30.noarch.rpm
Recap
We’ve covered the basics of how RPMs are built from a spec file. This is by no means an exhaustive document. In fact, it isn’t documentation at all, really. It only tries to explain how things work under the hood. Here’s a short recap:
RPMs are of two types: source and binary.
Binary RPMs contain the files to be installed to use the software.
Source RPMs contain the information needed to build the binary RPMs: the complete source code, and the instructions on how to build the RPM in the spec file.
The spec file has various sections, each with its own purpose.
Here, we’ve built RPMs locally, on our Fedora installations. While this is the basic process, the RPMs we get from repositories are built on dedicated servers with strict configurations and methods to ensure correctness and security. This Fedora packaging pipeline will be discussed in a future post.
Hands On: Overland Is A Game Where You Can’t Always Save The Dog
Overland has been in development for a long time now.
While Overland has been worked on, publisher Finji put out games like Canabalt (one of the very first endless runners) and Night in the Woods. In recent times, they’ve made press for games like Wilmot’s Warehouse and Tunic, one game about basically just a square and the other, an epic about an adventuring fox. Yet all the while, Overland remained in the background, tinkered, toiled, and iterated. It became a highlighted game for Apple Arcade, it laboured into almost 600 development builds (according to their Twitter), and after five calendar years, it’s finally putting all pre-release builds in the rearview mirror. Here it finally is: Overland 1.0.
It’s worth a mention that during that long stretch of development time, the themes and pieces that make up Overland are far more commonplace in the gaming industry: its a post-apocalyptic, gridded strategy game, not unlike seemingly a dozen games a year. You may or may not be able to pet the dog. And please, oh please, autocorrect… stop trying to autofill these impressions with “Overwatch” or “Borderlands”.
But what Overland has going for it – and this is clear in even just half an hour with the game – is fantastic production values and gameplay that’s been heavily user-tested. You like your X-COM baddies looking sharp and with a dash of character? Do your procedurally generated games feel a little too random, not methodical enough? From the second you pick up the controller, Overland feels crisp, well written, and difficult, but fair.
Here’s all Overland wants you to do: get to the west coast of the United States any way you can. The problem is that you start off on the east coast, moments after hijacking a stray car and zooming away from your friend who gave his life to afford you a few extra seconds to escape an attack. Enter: the map.
Having a car is the (mostly) mandatory bit of the game, as it helps you to travel from grid to grid. You stay on each grid as long as you want (or can), with an exit available on the map’s edge, provided you can get to it. Your vehicle has a gas meter, and the further up and down the map you want to travel to, the more gas it’ll take. Each node along your path gives minimally two options with hints to what’s hidden there, again, provided you have enough gas to get to them.
Explore the unknown at your own risk, because running out of gas drops you in an enemy-infested grid with gas canisters scattered everywhere, but with hardly any options open to you but brute force.
The other mandatory win condition is that you must have at least one living party member at all times (yep, even a dog counts). Each person you find along the way comes with their own written backstory, skills, and all kinds of potential. We quickly met a girl with a flashlight, which definitely helped. Why? Well, time is a thing in Overland, and it gets dark, which drastically affects your field of view. Turns out, being able to see is important in a turn-based strategy game.
To that end, items like the aforementioned flashlight are the other things you’ll discover besides gas; useful items are tucked away in alleyways, dumpsters, boxes, near explosive generators, and much more. We found a big, wooden plank, which we strapped to one of our character’s backs and it absorbed two hits from one of those gross monster things. We dropped a teddy bear because we could only hold one item, despite its promise as a good thing to barter later on. A stick as a weapon was also in our path, which we picked up in order to avoid the pyrrhic victory we’d get from chasing the sturdier axe in the corner that was guarded by way too many bad guys.
That’s how Overland bills itself: a game of “hard choices”. And it’s true. In this way, permadeath isn’t a thing to avoid as much as it’s Overland’s currency. Who will you sacrifice to get at least one person through the grid? Given how valuable each item is, how critical gasoline is, and how detailed all the characters are, this game wants to give you an aneurysm. But a good one, if such a thing can exist.
At least the grids where you’ll be making all these tough decisions are beautiful. The game allows you to rotate each screen ever-so-slightly, but you’re mostly confined to an isometric view of wasteland America, displayed by Polly Pocket-slices of dilapidated towns, scary wooded areas, and rural, destroyed countryside. Everything in this game is made out of large polygons, giving the destruction a sleek, “video-game-y” feel, but the colour palettes are warm and muted to keep things bleak. It’s a nice way to take in the end of the world.
The levels are randomly generated, but there is a narrative story. Finji tells us you can beat the entire game in about four hours… but you won’t. That is, Overland is tough as nails. It takes a few, quick play-throughs to get your bearings, some more to build up strategy, then a few more on top of that to get lucky. A game over screen features a post-mortem and stats for every member of your party that went along for the ride, and works as motivation to get back up and try again. If there weren’t so many pre-booked appointments at PAX, we might have even tried again after our party perished.
If you’re a fan of FTL and Into the Breach, or other similarly-minded stat-driven, hard choice strategy games, Overland will absolutely keep your attention. If anything else, it might be the first video game ever made where players actually choose to sacrifice the dog. Listen, it’s the only way.
New Resident Evil Game, Project Resistance, Gets First Trailer
Capcom has officially revealed a new Resident Evil game called "Project Resistance." Its existence has been known for some time now, with leaks indicating that it would be a multiplayer experience of some sort. The official trailer, released as part of the Tokyo Game Show, confirms this to be true.
Four characters are shown fighting their way through an office building-like setting, using guns and melee weapons to take out zombies and work their way through a series of sticky situations. Interestingly, another figure is shown to be orchestrating everything from the comfort of what looks to be an Umbrella lab; the shadowy organization no doubt has a big part to play in events, as is usually the case with Resident Evil games.
Alongside the classic shambling undead, Project Resistance will be pulling from the Resident Evil franchise's more iconic enemies. The trailer ends with the Tyrant appearing and the mysterious figure pulling strings behind the scenes assuming control, hinting that a player will be able to take control of enemies in the game. All of this gives it a definite Left 4 Dead feeling.
Project Resistance looks to be a four-versus-one asynchronous online multiplayer game. It's developed on the same engine powering the Resident Evil 2 remake. As of yet, there hasn't been any details on when the game will be released and, given the title, it may be some time before the final version is launched.
From September 12 through September 19, Xbox One and PS4 owners in Japan that are interested in the game can sign up for a chance to be invited into a closed beta for Project Resistance. The beta will take place from October 4 to October 7. Details on a beta outside of Japan have not been revealed yet.
Those at Tokyo Game Show, meanwhile, can get their hands-on with the title but need to have registered in advance to do so. Project Resistance will have a booth at TGS where attendees can watch members of the development team show off gameplay for the first time. Capcom has not indicated whether this footage will be released for those not in attendance to see.
The last Resident Evil game to be released was the remake of Resident Evil 2, which GameSpot awarded a 9/10. "Resident Evil 2 is not only a stellar remake of the original, but it's also simply a strong horror game that delivers anxiety-inducing and grotesque situations, topping some of the series' finest entries," said Alessandro Fillari. "But above all, the remake is an impressive game for the fact that it goes all-in on the pure survival horror experience, confidently embracing its horrifying tone and rarely letting up until the story's conclusion. Though Resident Evil 2 has its roots firmly in the past, it reworks the familiar horrors into something that feels brand new and all its own." You can read the full Resident Evil 2 Remake review for a more thorough analysis of the game.
CloudBees And Google Cloud Partner To Accelerate Application Development On Anthos
CloudBees and Google Cloud are collaborating to deliver a modern DevOps platform based on open source technologies powered by Google Cloud’s Anthos. The companies are using transformational technologies like Jenkins X, Kubernetes and Tekton to create a unified, end-to-end software delivery system. CloudBees provides companies large and small with Jenkins-based continuous delivery solutions that are secure, open toolchain-enabled and scalable to transform software delivery processes across hybrid computing environments. Google Cloud is delivering to enterprises a secure, open, intelligent and transformative enterprise cloud platform. Anthos, a hybrid and multi-cloud platform, is built on open source technologies pioneered by Google Cloud and enables consistency between on-premise and cloud environments. (Source: Press Release)
Announced a few months back at SIGRAPH, Maxon have finally released Cinema 4D Release 21. Perhaps the biggest and most contraversial new feature of this release is the change to a single SKU, combined with a new subscription based licensing model.
Maxon, the leading developer of professional 3D modeling, animation and rendering solutions, today announced the availability of Cinema 4D Release 21 (R21). The next generation of the professional 3D application features a completely new Caps and Bevel system, new Field Force dynamics, interface speed enhancements, and numerous rendering, workflow and core performance improvements. With Release 21, Maxon initiates a new singular version of Cinema 4D and new low-cost subscription pricing plans to ensure easy access to creatives.
“Release 21 delivers innovations and efficiencies that extend our objective to help customers meet the shifting needs of the competitive content creation industry,” said Maxon CEO Dave McGavran. “Simplified access to Cinema 4D and low-entry pricing allow artists to focus less on budget and more on the creative process.”
You can learn more about Cinema4D r21 here with the full release notes available here. Check out the video below to learn more about the new purchasing options and subscriptions available.
If you start talking to people about Battle Chasers, you’ll find that just about everyone had their own approach to the game. That’s a mark of a complex and well-designed system. None of the six characters can be absolutely pigeonholed into traditional RPG roles, and the many ways that they can buff, debuff, heal, and damage will result in individual approaches across the board.
So experiment! Look for synergies within character’s attacks and abilities, and across characters. It’s tough to build a character totally wrong if you’re keeping mind of their natural advantages. That said, here are some general tips for getting the most out of the game…
Tips & Tricks
The Attack modifier affects all of your combat abilities, including defensive and healing abilities! Boosting your Attack is the fastest way to use more effective moves in combat. Because Attack even affects your characters’ defensive and healing moves, it is usually a better choice to buff Attack rather than Defense when you find you are taking too much damage.
Your characters’ level also makes a huge difference in terms of their strength–all the attributes in the game are scaled according to level. If you’re having trouble on a boss, grinding out a single level will probably make up the difference. The Arena is a great place to quickly nab some experience.
One unique feature in Battle Chasers is the Haste system. In addition to the initiative scores that determine who goes first, faster characters also get their attacks off faster. An attack that is too slow may allow an enemy to slip in their own attack before you finish! Abilities that add Haste can make Very Fast abilities instantaneous, giving you more control over the pace of the battle and more attacks compared to your opponents.
While initially it seems like Overcharge is a kind of bonus mana, it’s actually a much more powerful replacement for mana. Once you have the ability to quickly build up your Overcharge, there’s no need to keep a reserve of mana–in fact, it can be to your detriment. Some perks gain big bonuses if you have a large reserve of Overcharge, but having full mana limits your potential Overcharge pool. Drain your mana in some easy fights if you need to, so you can save space for a big Overcharge bonus.
Some final tips:
Don’t forget to equip your perks, and switch them around when you need to try something different.
Dungeon skills are also a big help if you’re struggling with a fight.
Debuffing the enemy before the battle will give you a huge advantage.
Don’t neglect to eat.: There’s a lot going on in this game, but food can give you big bonuses that you will especially appreciate before a boss fight.
Character Notes
Garrison
With Overcharge being such a key mechanic of Battle Chasers, Garrison is the DPS-generating heart of any solid team. He has a larger Overcharge pool and Overcharge-generating attacks and abilities. His Warblade ability will quickly become one of the strongest attacks in the game once you master building his Overcharge pool. At the beginning of the game, his Rally Strike is a useful first cast that will boost your whole team’s Haste. You can also go with attacks that cause bleeding and use Siphon to heal.
Gully
Gully is a versatile character that can serve as a tank or a defensive caster, but also hits hard enough to help in dealing damage. Her Taunt ability is key for tanking, and will keep the bad guys off of your more vulnerable characters, while Defend makes her nigh-invincible. Gully is always a good choice for a dungeon crawl, since she can smash her way through secret passages–look for the dust coming out of the wall.
Calibretto
This giant war golem has an interesting mix of healing and damaging abilities, making him a great addition to any party. At the beginning, you’ll definitely want him on healing duty, but consider branching out to DPS. His Sundering abilities are big damage boosters, especially combined with Gut Punch II that also builds Overcharge.
Knolan
Knolan is a tougher character to use, since he builds Overcharge much more slowly and relies on his mana pool far more than other characters. However, his spells are great for crowd control and debuffing your targets. You’ll be relying on Calibretto for healing by the time you get Knolan, but Knolan can also work well as a healer.
Monika
Red Monika is also a great damage-dealer, so you should probably choose between her and Garrison. She relies on building up her critical hit chance for doing huge amounts of damage. Another option is to use her as an evasion tank with her Camouflage abilities.
Alumon
Alumon comes in later in the game, but will become a part of many parties thanks to his jack-of-all-trades skill set. He is also a great healer. He may even be a better choice than Calibretto because his overheals can become shields with his Grim Covenant ability.
Do you have any tips or tricks of your own? Let us know in the comments!
Since we GA’ed Azure SignalR Service in last September, serverless has become a very popular use case in Azure SignalR Service and is used by many customers. Unlike the traditional SignalR application which requires a server to host the hub, in serverless scenario no server is needed, instead you can directly send messages to clients through REST APIs or our management SDK which can easily be used in serverless code like Azure Functions.
Though there is a huge benefit which saves you the cost of maintaining the app server, the feature set in serverless scenario is limited. Since there is no real hub, it’s not possible to respond to client activities like client invocations or connection events. Without client events serverless use cases will be limited and we hear a lot of customers asking about this support. Today we’re excited to announce a new feature that enables Azure SignalR Service to publish client events to Azure Event Grid so that you can subscribe and respond to them.
How does it work?
Let’s first revisit how serverless scenario in Azure SignalR Service works.
In serverless scenario, even you don’t have an app server, you still need to have a negotiate API so SignalR client can do the negotiation to get the url to SignalR service and a corresponding access token. Usually this can be done using an Azure Function.
Client will then use the url and access token to connect to SignalR service.
After clients are connected, you can send message to clients using REST APIs or service management SDK. If you are using Azure Functions, our SignalR Service binding does the work for you so you only need to return the messages as an output binding.
This flow is illustrated as step 1-3 in the diagram below:
What’s missing here is that there is no equivalent of OnConnected() and OnDisconnected() in serverless APIs so there is no way for the Azure function to know whether a client is connected or disconnected.
Now with Event Grid you’ll be able to get such events through an Event Grid subscription (as step 4 and 5 in the above diagram):
When a client is connected/disconnected to SignalR service, service will publish this event to Event Grid.
In Azure function you can have an Event Grid trigger and subscribe to such events, then Event Grid will send those events to the function (through a webhook).
How to use it?
It’s very simple to make your serverless application subscribe to SignalR connection events. Let’s use Azure function as an example.
First you need to make sure your SignalR Service instance is in serverless mode. (Create a SignalR Service instance if you haven’t done so.)
Create an Event Grid trigger in your function app.
In the Event Grid trigger, add an Event Grid subscription.
Then select your SignalR Service instance.
Now you’re all set! Your function app is now able to get connection events from SignalR Service.
To test it, you just need to open a SignalR connection to the service. You can use the SignalR client in our sample repo, which contains a simple negotiate API implementation.
Hands on: Sonos Move fits in the home as well as outdoors
Sonos has just made its new portable Wi-Fi and Bluetooth speaker official with the announcement of the Sonos Move, alongside the Port and the One SL. AppleInsider was in New York City with Sonos to try the speakers.
Introducing Sonos Move —The first portable speaker for Sonos
Recently, Sonos held a press event in New York’s legendary Milk studio, where its CEO unveiled a trio of new devices to a mass of onlooking journalists. AppleInsider was in attendance and got the opportunity to try out the new devices, including the Move —Sonos’s first portable speaker.
Today, the Sonos Move, Port, and One SL are official, ending a long trickle of high-profile leaks.
The first Sonos portable speaker
The most exciting of the new products is the Sonos Move. Sonos Move is, as the company describes, a culmination of all its work to date. Outdoor speakers, especially Wi-Fi connected ones, are much more difficult than indoor speakers to execute well, and the company thinks that it has it all figured out.
Sonos Move works just as well in the home as outside the home
Outdoor speakers need to be durable, have long-lasting batteries, good connectivity, and loud. That is exactly what Sonos has done with the Move.
The Sonos Move is weighty —over six pounds —and had a solid, premium feel to it when we hoisted it. Compared to other portable speakers, Move seemed to be on the large size but once we heard the sound it was capable of, and its list of features we understood.
The Sonos Move isn’t a mass-appeal Bluetooth speaker that can be clipped to a backpack. Instead, it is marketed as a home speaker that can also be taken outside the home.
Sonos can stream over Wi-Fi and group with other Sonos speakers. Even works with AirPlay 2 and HomeKit
To that end, Move can operate entirely the same as any other Sonos speaker. It can connect over Wi-Fi, be grouped with others in the home, and even work with AirPlay 2. A simple dock gives it a place to rest when in your home, whether in the kitchen or on a desk.
What separates Move, is that it can then be picked up, separated from the dock, and taken anywhere, wire-free. If near your home —say out on the patio —the speaker can continue to stream over Wi-Fi. If away from the home, a button press on the back switches the speaker to Bluetooth mode.
Wirelessly, Move can jam on for ten hours. It can also be recharged on the go with a USB-C battery pack. Unfortunately, there is no USB output for charger other devices from the Move.
A button on the back toggles between Wi-Fi and Bluetooth
Sonos also touts Move as the most impressive wireless performance of any of its devices. It supports 802.11b/g/n at 2.4 and 5GHz and Bluetooth version 4.2. We will have to test the wireless range for ourselves, but Sonos assures us we will be impressed with the range.
One thing we were particularly impressed by with the Move was standby mode. After a period of inactivity, Move drops into a low-power suspend mode to conserve battery. Even while in this mode, it is instantly reachable whenever playback is to resume, including over AirPlay 2.
Sonos says that standby mode can be maintained for 120 hours on one charge.
Controls are familar on top of Sonos Move
On top of the Move are four far-field microphones. They are used for a user’s assistant of choice —either Amazon Alexa or Google Assistant, no Siri here. A chime alerts users when the assistant is listening and it can also be muted.
Those microphones also serve another purpose. Sonos has adapted its Trueplay tuning technology to happen on-device.
With other Sonos speakers, to use Trueplay, users must walk around the room moving their iPhone around. With Move, since it isn’t always guaranteed to be in one place, it needed to be able to tune itself.
A gyroscope is inside Move so that whenever it is relocated, it will use the four microphones to automatically adjust playback to its new location. This is very similar to how Apple tunes HomePod. Sonos said it was able to crowdsource a significant amount of data from users’ manual tuning to allow Move to do it on its own.
Outdoor sound
Sonos Move is rugged for outdoors adventures
Taking an indoor speaker outside is usually not a worthy endeavor. The speakers aren’t loud enough and have narrow sound spaces. Move, is designed to be outdoors, and is much more powerful. We listened to Move —however briefly —indoors and outdoors and came away impressed with how loud the Move could get. It easily will fill small to medium gatherings.
Sonos did, purposefully, design the Move with directional sound, rather than omnidirectional like the Libratone Zipp 2 or HomePod. They met in the middle by creating a very wide soundstage, so even though it only comes out one side, it is enough to cast a wall of sound. This is something we will continue to test in our full review.
There was a substantial amount of bass with the Sonos Move, something Sonos also focused heavily on with countless iterations on the cabinet design, many of which were on display at its press event.
The little things
There were two clear messages out of our time with the Sonos team. Sonos says that this speaker is multi-purpose for in and outside the home, and they claim to have focused on the fine details that make or break a product.
The battery should be replaced after about three years of use
We heard many, many times how the speaker is designed to last, so Sonos engineered a battery that could be swapped after around three years of use and software updates. We heard how Sonos worked on powerful antennas to keep Wi-Fi reliable. We heard about the iterations of colors until they found one that had the most appeal, could withstand UV rays, and wouldn’t look dirty.
The Sonos Move dock charges the speaker and gives it a place to live inside the Home
That includes the dock itself which is used to charge the Move. Sonos said without a dock, users would set the speaker down right next to the charger but wouldn’t go the extra step of plugging it in unless necessary. The dock was also designed to automatically align the speaker so that when it was placed, even haphazardly, it would settle correctly and charge.
Sonos also spent substantial time on protecting the Move. During the demo, journalists were invited to torture several different Moves with various scenarios such as a dust chamber, a water chamber, and a drop test. As far as ratings go, the Move has earned an IP56 designation which means it can keep out most dust and can withstand water jets from any direction though it can’t be submerged underwater.
Sonos Move
We were told that users could inadvertently leave Move outside overnight in the rain and it would still be undamaged by morning.
Sonos Move is a big step for the speaker maker, finally venturing outside the home. It has built upon its roots and expertise creating a powerful, portable speaker. We are eager to further test the Move for ourselves in our environment, but what we saw —and heard —left us eager to listen more.
Sonos Port
The second product announced is the new Sonos Port, the successor to the Sonos Connect.
Sonos Port
It was upgraded with AirPlay 2 support and will allow users to play their favorite audio to their existing amplified audio equipment.
There is line-in to connect CD or vinyl players to the Sonos system as well. The new design allows it to be rack-mounted, beneficial for commercial installations. An added 12V trigger can also be used to turn on an external amplifier.
Sonos One SL
Sonos One SL has no microphones
Lastly, we have the Sonos One SL. It looks and sounds exactly like the Sonos One, just without the array of microphones on top. There are no microphones on this device, which also means no smart assistant. For privacy-focused individuals, this is an option that gives you Sonos sound without the compromise.
Otherwise, it is the same as the Sonos One with dual class-D amps, a tweeter, and a mid-range woofer. Controls are on the top and a 10/100 ethernet port is around back.
Availabiilty
Sonos Move will be available starting September 24 for $399. Sonos One SL is available starting September 12 for $179, and Sonos Port is available September 12 for $399.
