MvxTrace output in WPF project - mvvmcross

I'm not seeing any MvxTrace output in my WPF project. I'm using the default project template created by NuGet.
Is there anything special that must be done or is this a bug?

The default WPF project provides debug output via MvxDebugTrace
For Release assemblies (such as those included in Nuget) this obviously does nothing.
If you want to link to the release assemblies but use Debug output, then you can do so by implementing IMvxTrace and by providing your implementation during setup - you'll need to override protected abstract IMvxTrace CreateDebugTrace(); - in https://github.com/slodge/MvvmCross/blob/v3/Cirrious/Cirrious.MvvmCross/Platform/MvxSetup.cs#L25

Related

compile razor views in .net core

Is there a way I can compile all my razor views (to verify) any time I need? I found this doc which shows how it compiles on publish https://learn.microsoft.com/en-us/aspnet/core/mvc/views/view-compilation?view=aspnetcore-2.1&tabs=aspnetcore2x.
I am looking for an option within visual studio or even better via CLI that compiles and validates all views. I did find this official razor CLI tool in preview, but no documentation: https://www.nuget.org/packages/Microsoft.AspNetCore.Razor.Tools/1.1.0-preview4-final
Well, you can publish any time you need. The name ‘publish’ does not mean ‘push my site to the coliseum of public opinion’ :-)
All that it does stays local, and dotnet publish will by default create a directory under your project bin folder with, as you say, compiled views and other artefacts.
Per this comment, with .NET core 2.1 you can compile razor views at build time without needing to publish, by adding these two lines to the <PropertyGroup> section of your project file:
<RazorCompileOnBuild>true</RazorCompileOnBuild>
<ResolvedRazorCompileToolset>RazorSdk</ResolvedRazorCompileToolset>
This will cause them to compile to a [project].Views.dll, and you'll no longer need to distribute the cshtml files.

Error accessing WinRT sensors in C++ desktop application

I am trying to access the WinRT sensors from a Win32 desktop application using C++/CX as mentioned here: https://software.intel.com/en-us/articles/using-winrt-apis-from-desktop-applications
When I include the C++/CX header file it causes an error when building the Win32 project.
Exact error text: "error C1190: managed targeted code requires a '/clr' option."
Since I am not using /clr code at all, this is a confusing error.
Any suggestions? Please educate me if there is a better way to do this.
The error you are getting is because you are compiling some files without /ZW option for compiler. Since you are able compile at least some files with WinRT extensions, but not others, your project configuration is inconsistent.
The option /ZW (enable WinRT extensions) has to be configured on the level of project (and not on the level of individual files). There are two ways to ensure your settings are consistent. First method is through UI in Visual Studio -- you have to go through all platforms/configurations on the project and ensure /ZW is enabled, then got through all indivudual .cpp files, and ensure they don't override project level settings. This is tedious and error prone. The easier method is to open .vcxproj in notepad and do the following:
Add this section at the beginnig of the file, under root Project node:
<ItemDefinitionGroup>
<ClCompile>
<CompileAsWinRT>true</CompileAsWinRT>
</ClCompile>
</ItemDefinitionGroup>
Search and remove any other places where <CompileAsWinRT> is defined.

How to package a Windows Runtime component for distribution?

I have built a WinRT component (.winmd) for use by both JavaScript and XAML Windows Store apps. When including and referencing the loose .winmd file output in a JavaScript client, I see this build warning:
Microsoft.AppXPackage.Targets(808,9): warning APPX1707: No implementation file was provided for the .winmd file 'myRuntimeComponent.winmd'. To generate registration information in the app manifest, specify the 'Implementation' metadata on the .winmd reference item in the project file.
I can't find any documentation on this error or how to include implementation metadata.
When running the JavaScript client, this exception is thrown when a class method exported from the .winmd is called:
0x80040154 - JavaScript runtime error: Class not registered
Note that I am referencing the loose .winmd file in the client application project, rather than referencing the Visual Studio project that builds the .winmd. My use case is distributing the .winmd output, not the full source for the .winmd component - source distribution is not an option.
Also note that when the Windows Runtime component is referenced as a project reference, the JavaScript client builds and runs correctly. The C# XAML client runs correctly with either a project reference or a reference to the loose .winmd.
It seems as if some registration information is not being generated in the client application build when a loose .winmd is referenced.
How can I build and distribute a loose Windows Runtime component for use by both JavaScript and managed clients?
A WinRT component built with C# or VB produces a .winmd that contains both metadata and implementation. A component built with C++ provides separate .winmd and .dll files, and the DLL is what contains the details to register the component.
Apparently, as the warning indicates, you need to edit the project file with something like the following to point to the DLL:
<Reference Include="component">
<HintPath>component.winmd</HintPath>
<IsWinMDFile>true</IsWinMDFile>
<Implementation>component.dll</Implementation>
</Reference>
Alternatively you might want to look into Extension SDKs. See the below link for how to package your component as an easy to consume Extension SDK in VS:
http://msdn.microsoft.com/en-us/library/jj127119.aspx

Strange issue when adding a service reference to a project that has the JSON.NET library referenced

The project is your standard run-of-the-mill ASP.NET MVC 3 application that communicates with an in house WCF service. Our ASP.NET MVC application references a few external libraries, including the popular JSON.NET library.
The issue only occurs when the JSON.NET library is a reference in a project. I tried recreating this issue with a WebForms and a Windows Forms project, and the same thing happens.
When adding a service reference to our WCF service, and JSON.NET is a reference in our project, it builds the service reference like this:
With JSON.NET referenced in the project - notice the Request/Response Classes and the weird properties like Id1 and IdSpecified
But removing the reference to JSON.NET and updating the service reference builds it the way we want, like this:
Without JSON.NET referenced in the project
...
What in the world would cause this? JSON.NET is not referenced in the WCF project, so I highly doubt that there could be some sort of mix up there.
Some information that may help:
Tried checking various options in the Add Service Reference dialog such as "Reuse types in referenced assemblies" - but the same thing happens
Visual Studio 2010
WCF service uses Entity Framework for data access
When you add a service reference, WCF by default will reuse the classes from your assemblies that match the ones that will be generated otherwise.
This happens because, for example, you might develop both the service and the client and you might want to have a class library with all the classes referenced in both projects. This also makes sure that .NET default types (like arrays, lists, DateTime) are used.
You can change this default behavior like this:
Click the Advanced button after you selected "Add service reference"
Select "Reuse types in specified referenced assemblies"
Check all the assemblies, except the ones that you don't want to
use
Note that if you don't check the system assemblies, you will get a new type generated in the proxy file for every .NET type (like arrays, lists) as well.

Found conflicts between different versions of the same dependent assembly.MVC3 -> MVC4 / EF4 -> EF5

The question is how to resolve conflicts between versions of assemblies in my project that was upgraded to MVC4 and EF5?
The problem is manifest in the fact that my controllers and models can include System.Data.Objects, but now my views.
I am using MVC 4, my project was upgraded from MVC 3.
Entity Framework is version 5.
I have a controller that is able to use objectcontext from System.Data.Objects.
My Usings:
using System.Data.Objects;
using System.Data.Entity;
When I try to include the using in the view form System.Data.Objects, I get :
CS0234: The type or namespace name 'Objects' does not exist in the namespace 'System.Data' (are you missing an assembly reference?)
I am targeting .net 4.5
My Build Displays this message:
C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.Common.targets(1561,5): warning MSB3247: Found conflicts between different versions of the same dependent assembly.
You can build your solution in diagnostic mode to get more detailed information about the error.
Open the VS Options dialog (Tools > Options), navigate to the "Projects and Solutions" node and select "Build and Run". Change the MS Build project build output verbosity to Diagnostic.
Have a look here.
If you look at the build message, it states the 4.0 version of the .net framework is referenced... Is there a setting in your project file or web/app.config specifying a conflicting version of the .net framework?
Are you familiar with fuslog? you can set it up to log all assembly bindings that .net is doing while running your application. You should then be able to see detailed information on what is getting bound when. If you still can't figure it out, you can always do a binding redirect on that .dll in the web.config.
http://msdn.microsoft.com/en-us/library/eftw1fys.aspx -- binding redirects
http://msdn.microsoft.com/en-us/library/e74a18c4(v=vs.71).aspx -- fusion log viewer
Set up fusion logger and take a look at what the output is. If you don't get an answer from that, try the binding redirect (which would give you at least a temporary solution).
In the directory I was publishing to, there was a folder named aspnet_client. I moved it (instead of deleting it), republished, and it worked. I'm not sure why that folder decided to give me trouble out of the blue.