Visual Studio 2017 UWP csproj file format

I was working on a UWP store app that uses a .NetCore class library (DLL) and suddenly I got a range of strange errors from the NuGet packaging system. Everything Visual Studio 2017 tried to restore packages I got errors like this:

One or more projects are incompatible with UAP,Version=v10.0 (win10-arm).
Project GameEngine is not compatible with uap10.0 (UAP,Version=v10.0) / win10-x86. Project GameEngine supports: uap10.0.14393 (UAP,Version=v10.0.14393)
Project GameEngine is not compatible with uap10.0 (UAP,Version=v10.0) / win10-arm-aot. Project GameEngine supports: uap10.0.14393 (UAP,Version=v10.0.14393)
Project GameEngine is not compatible with uap10.0 (UAP,Version=v10.0) / win10-x64. Project GameEngine supports: uap10.0.14393 (UAP,Version=v10.0.14393)
One or more projects are incompatible with UAP,Version=v10.0 (win10-x86).
One or more projects are incompatible with UAP,Version=v10.0 (win10-x64-aot).
Project GameEngine is not compatible with uap10.0 (UAP,Version=v10.0). Project GameEngine supports: uap10.0.14393 (UAP,Version=v10.0.14393)
One or more projects are incompatible with UAP,Version=v10.0 (win10-x86-aot).
Project GameEngine is not compatible with uap10.0 (UAP,Version=v10.0) / win10-x86-aot. Project GameEngine supports: uap10.0.14393 (UAP,Version=v10.0.14393)
One or more projects are incompatible with UAP,Version=v10.0.
Project GameEngine is not compatible with uap10.0 (UAP,Version=v10.0) / win10-x64-aot. Project GameEngine supports: uap10.0.14393 (UAP,Version=v10.0.14393)
One or more projects are incompatible with UAP,Version=v10.0 (win10-arm-aot).
Project GameEngine is not compatible with uap10.0 (UAP,Version=v10.0) / win10-arm. Project GameEngine supports: uap10.0.14393 (UAP,Version=v10.0.14393)
One or more projects are incompatible with UAP,Version=v10.0 (win10-x64).

Searching online didn’t help much, but after I created a new skeleton solution with the latest version of Visual Studio 2017 I discovered a difference in the csproj files, this section:

<ItemGroup>
  <!-- A reference to the entire .Net Framework and Windows SDK are automatically included -->
  <None Include="project.json" />
</ItemGroup>

was replaced by this section:

<PropertyGroup>
    <RestoreProjectStyle>PackageReference</RestoreProjectStyle></PropertyGroup>

After replacing the old section with the new in the csproj file, everything worked again.

Root cause was that the UWP project was created by an earlier version of Visual Studio 2017 and the format has changed. But that was quite hard to read from the errors above 🙂

 

Anti Pattern – TODAY function

One of the oldest features in C/AL and the AL code before that is the TODAY function. It will return the current date from the local computer.

A close friend of TODAY is WORKINGDATE. Working Date is the concept of setting “today” to be something else.

When working with entering data, the ease of type t in a date field for today, and w for working date are good for entering data.

But what about when you’re using TODAY (or WORKINGDATE) in your code?

Yesterday I came across an example in one of our old products:

IF CALCDATE('CM+1D',DueDate) > TODAY THEN
    PostSomething()
ELSE
    PostSomethingElse();

Depending on the current date when the user pressed Post, different things would be posted.

It got me thinking, when is the use of TODAY appropriate in code?

The first valid use case would be to add a timestamp to records, field like “Modified Date, “Created Date”, “Approved Date”. Fields where you are recording the date of a user action.

In most other cases, you should use WORKINGDATE to give your users a chance to control the flow. And if actions in your code depend on Dates – let the user know about this.

Do you have other examples of the bad or good use of TODAY?

Inheritance security rules violated by type: Microsoft.Dynamics.Nav

If you get the following error:

Unhandled Exception: System.TypeLoadException: Inheritance security rules violated by type: 'Microsoft.Dynamics.Nav.WindowsServices.NavServerWindowsService'. Derived types must either match the security accessibility of the base type or be less accessible.
   at Microsoft.Dynamics.Nav.WindowsServices.DynamicsNavServer.Main(String[] args)

Then you have properly (as I did) updated your service tier with files from a zip file, that Windows Server 2012 have decided that are unsafe and need to be blocked. I got the error after a quick update of Microsoft Dynamics NAV 2017 to CU4.

The solution is easy, fire up PowerShell, and run the following command in the folders where you copied files:

dir -Recurse | Unblock-File

Then everything should work again 🙂

An adventure in Microsoft Dynamics NAV, .NET and other technologies