A newbie setup for Elmish.WPF in Visual Studio 2019 - wpf

At the risk of beating a dead horse, I would like to be clear on the initial setup for using Elmish.WPF.
My intent is to have essentially two projects:
FrontOfficeV -- a C# project to hold the XAML's, Windows, etc..
Models -- a F# project for Elmish.WFP, F# code, etc..
After trying most all of the project type options (Visual Studio 2019), I settled on: Console App (.NET Framework) C# for the C# Project.
This created the C# project that defaulted to: Target framework: .NET Framework 4.7.2 Output type: Console Application. This also created a "program.cs" file.
Next, using ADD -->New Item with the C# Console App did not show a "Window" option. It did show the "User Control (WPF)" option. So the "User Control (WPF) was added and renamed to "MainWindow". I then changed the element tag in the xaml from UserControl to Window and changed the code behind to inherit from Window instead of UserControl. Lastly, I changed the project properties to compile output type to: Windows Application. This C# project was now marked as the "StartUp" project for visual studio.
Next, the F# Models project was created using: Library (.NET Framework) F# Windows library. This created a project which defaulted to: Target framework: .NET Framework 4.7.2 Output type: Class Library. To the F# class library, a program -- FrontOffice.fs, was added with:
/// This is the application's entry point. It hands things off to Elmish.WPF
let entryPoint (mainWindow: Window) =
Program.mkSimpleWpf init update bindings
|> Program.runWindowWithConfig
{ ElmConfig.Default with LogTrace = true; Measure = true; MeasureLimitMs = 1 }
mainWindow
Lastly, the program.cs was changed to read:
public class Program
{
[STAThread]
public static void Main(string[] args)
{
Application app = new Application();
Window mainWindow = new MainWindow();
Models.FrontOffice.entryPoint(mainWindow);
}
}
The point here being the usage of: Program.mkSimpleWpf.
Why all the hassle? I would like to use the full WPF/C#/XAML goodies (like Themes, custom controls, etc), and I am not so sure the direct compilation of XAML in F# can do this. I'd like to be able to use the F# data types in the XAML, so the C# project requires a reference to the F# Modules, so it seems easier to create the windows in C# and pass a reference unto the F# Modules entryPoint, as above.
Questions:
Is the setup above correct for Elmish.WPF?
Is there a better setup to accomplish my goals?
As of Visual Studio 2019, does F# compilation of the xaml work for themes, custom controls, etc? What hiccups can I expect?
Thank you for any clarification on these points. TIA

Related

Intillisense fails on undefined namespace in XAML on Visual Studio 2010

I must be brain dead. I have tried for six hours now (with Google) and can not solve this very very simple problem.
In Visual Studio 2010, I created a project. (right-click on solution, Add new project...).
Inside the new project, I created a new folder of name Helpers. To the folder I added a class for a converter.
Inside the project, I added a new XAML window (in WPF). The Target Framework is .Net Framework 4.0
Everything has been built (multiple times) without compilation errors. The platform target build for the project is X86.
The problem: Intellisense does not see the namespace for the class under the Helpers folder and so the Visual Designer fails. The namespace in the Helpers folder is:
Chaos.UI.Helpers
and trying to reference this namespace in the XAML like:
xmlns:converters="clr-namespace:Chaos.UI.Helpers"
ofcourse results in the dreaded:
Undefined CLR namespace. The 'clr-namespace' URI refers to a namespace 'Chaos.UI.Helpers' that is not included in the assembly.
These are clean files in the same project. The only added code is in the converter class contained in the Chaos.UI.Helpers namespace.
How do I fix this? (I need the designer to work).
Anybody, Plz help
Try use assembly
xmlns:converters="clr-namespace:Chaos.UI.Helpers;assembly=Chaos.UI"

Adding a WPF form to a library in visual studio express

I managed to create a WPF project, but for some reason, when instead I am in a library project and I try 'Add Item', then go to WPF, there is only one thing I can add, which is a user control.
I am not clear what a user control is, but clearly it has no 'Show' method.
If instead I tried copying the mainwindow from my WPF project to the library project, but then it would not compile (and I added missing references).
Am I doing something wrong, or is Visual Studio Express for Desktop just not featuring a WPF form?
EDIT: it seems I am after a WPF window instead (as per the Mainwindow : window class that gets generated when creating a new WPF app), not a form.

Building IronRuby WPF GUIs

This may be a silly question but I was under the impression that it was possible to use IronRuby and MS Visual Studio 2010 together to sort of build interfaces\edit XAML in one window and code ruby in the other?
Is this only possible to do with C#, Basic and C++ ?
I've browsed SO and seen some IronRuby snippets like this one:
button1.click do |sender, args|
MessageBox.show("Hello World!")
end
So it stands to reason you can create GUIs somehow, but is the visual gui creator not available for ironruby?
In order to build GUIs you should use XAML with WPF. You can create XAML with the editor in Visual Studio. Running a XAML file is possible with:
require "PresentationFramework"
include System::Windows
include System::Windows::Markup
xaml = File.Open('d:/app/window1/xaml', "r").read
#root = System::Windows::Markup::XamlReader.parse(xaml)
app = System::Windows::Application.new
app.run #root
Please refer to IronRuby Unleashed for more information

Errors when referencing Silverlight class library from WPF application

I have a WPF application and a Silverlight application. They are both used to display a map and share some of the same functionality.
I have created a Silverlight class library project in order to stay DRY. I'm referencing this from both Silverlight and WPF. It contains some utility methods that are useful in both projects. For example, I have this method:
public static void CenterText(TextBlock name, Polygon poly)
The silverlight project has no problem with this. However, I get the following error when calling this from my WPF application:
The type 'System.Windows.Shapes.Polygon' is defined in an assembly that is not referenced. You must add a reference to assembly 'System.Windows, Version=2.0.5.0, Culture=neutral, PublicKeyToken=7cec85d7bea7798e'
However, I have this line at the top of the file:
using System.Windows.Shapes;
so WPF can see the Polygon class perfectly fine.
My guess is that the silverlight class library uses a version of the framework which is not compatible with the version that the WPF project is using.
So the question is, am I stuck rewriting exactly the same code in my WPF application or is there some way I can share between the two?
Thanks!
You are right, Silverlight uses a completely separate version of the framework. It's much, much smaller than event the .NET client runtime.
This means you can't mix WPF and Silverlight assemblies in the same application.
I ran into this error because I had downloaded the Expression Blend SDK for Silverlight instead of what I SHOULD have downloaded: Microsoft Expression Blend Software Development Kit (SDK) for .NET 4. It can be found on MSFT's website, here:
http://www.microsoft.com/en-us/download/details.aspx?id=10801
As soon as I downloaded the Expression Blend SDK for .Net, removed all of the Blend SDK for Silverlight references, and added those same references as Blend for .Net, I was up and running.
In Silverlight the class is in System.Windows.dll while in WPF it is in PresentationFramework.dll the library tries to get a hold of the Silverlight assembly which is not referenced by default in a WPF application.

Visual Studio 2010 uses Application.xaml; Blend 4 uses App.xaml

Previously all application level resources in a project I am authoring were stored in App.xaml. Then I decided to migrate from VS 2008 to 2010 and that is where the trouble started.
After migrating, I tried to do a little testing using a testing window instead of the normal startup window. After changing the startup object, suddenly I was faced with lots of compile errors and what not which (long story short) resulted in finding that there was now two files which held application level resources associated with the project: App.xaml (the original), and Application.xaml (at this time veritably empty). I migrated all of the resources (as well as merged dictionaries) over to the Application.xaml, and all was again right with the world so far as Visual Studio was concerned.
I then found out that Blend still wanted to use the App.xaml. I had created several resources and placed them in the Application.xaml, and saw that they were not being used when I compiled with Blend (but they were being used when I compiled with VS).
Where does one specify which XAML is the top level WPF resource file? This is getting out of hand...
There are slight differences in naming depending on what programming language you choose.
Visual Basic WPF projects use Application.xaml, while C# projects name it App.xaml.
As you probably know all .NET apps need a Main method. Also, windows apps need a message pump to get hooked to the Windows messaging system. IN WPF you can use the Application class to start listening to the windows messages.
Here's how you can do it explicitly.
VB
Public Class Startup
<STAThread()>
Shared Sub Main()
Dim app As New Application()
Dim window As New MainWindow()
window.Show()
app.Run()
End Sub
End Class
C#
public class Startup
{
[STAThread()]
public static void Main()
{
Application app = new Application();
MainWindow window = new MainWindow();
window.Show();
app.Run();
}
}
Since creating this type of code is common for WPF applications you can tell MSBuild to write this code by defining a XAML file and class that derives from System.Windows.Application and specifing its build action as 'ApplicationDefinition'.
In your situation, instead of editing the VbProj file, you could just select the correct file in Solution Explorer and change the BuildAction.

Resources