How can I add a Xamarin.Forms XAML file to an FSharp project?
By default, XAML files have C# code-behind.
I tried moving a XAML file with C# code-behind to an F# project.
I then changed the file extension to ".fs".
However, my attempt crashed VS2017.
EDIT
C# Views & F# ViewModels
I'm guessing WPF and Xamarin.Forms will see this the same way. You can define all your views in your C# project and have your ViewModel logic in a Portable Class Library (PCL). You can refer your ViewModels directly in your C# project when the View needs its DataContext. This way, it'll behave the same way as it would with a C# ViewModel.
If you'd like a working example of this, I found this that shows exactly what you could do: MVVM with F#
F# MVVM
If you'd prefer to have an entire application that has F# business logic and XAML in the same project, you can download the following extension: Windows App in F#. By pointing to the FSharp.ViewModule in your directives, you'll be fine.
The view model which will handle all UI logic. Inherit view model from
ViewModelBase
You'll also be able to find a working sample of this kind of thing right here
"Code behind" files don't exist in F# (lack of partial classes), and even in C# many people recommend keeping those files empty.
You can load the Xaml file using .LoadFromXaml and access objects using .FindByName<'t>. See Wintellect sample. You need to specify the names as strings and the types so there isn't compile-time safety.
It is not as clean as on WPF, where there is a type provider (FsXaml) which gives typed access to the objects. A type provider for Xamarin Forms may appear in future.
I personally prefer to avoid Xaml and do everything in code, where everything is typed and there is no reliance on strings.
Related
Using the base Exrin template, I am unable to use custom controls.
As it stands now, the Droid/iOS projects reference the App/Bootstrapper project, so that seems like the correct place to put them, but when creating a new page or BaseView, I am not able to access the custom control's namespace because the View project does not reference the App/Bootstrapper project.
The Tesla sample app does not have this problem in its current implementation since there is no separation of the App/Bootstrapper and the View projects.
(1) Should a reference to the App/Bootstrapper be placed in the View project or (2) should a reference to the View project be placed in the Android/iOS/etc projects? Or is there a better solution than either of these two?
Edit:
(1) does not work because a reference to the App project from the View would create a circular dependency.
(2) should work (I think), but I'm having trouble getting the Application.Droid project to access the Application.View project namespace because when I add using Application.View;, the namespace isn't found in the Application namespace. Visual Studio attempts to fill in other Application namespaces (.Container, .Logic, .Droid, .Proxy) when I type in using Application.
The native project can have a reference to the View. It already does in a way, because it references the App library, which then references the View. Hence you aren't really adding any further dependencies by doing this, just allowing access further up the chain.
If you are having trouble the namespace, I suggest you start out with
global::Application.
That way it starts from the top, if its getting mixed up with project namespaces.
I understand C# Code Fragments and .NET Assemblies offer the same functionality for modular template development. We manage the code fragments in the CME and assembly code in Visual Studio, but use both the same way in Template Builder.
In terms of code, I can create a C# Code Fragment Template Building Block (TBB), for example:
var timeStamp = DateTime.Now.ToString("d MMM yyyy");
package.PushItem("timeStamp from fragment", package.CreateHtmlItem(timeStamp));
I can also create a .NET assembly Template Building Block using the same code by implementing ITemplate as below.
using System;
using Tridion.ContentManager.Templating;
using Tridion.ContentManager.Templating.Assembly;
namespace CreateAndBreakTemplates
{
[TcmTemplateTitle("Add Date to Package")]
public class AddDateToPackage : ITemplate
{
public void Transform(Engine engine, Package package)
{
var timeStamp = DateTime.Now.ToString("d MMM yyyy");
package.PushItem("timeStamp from assembly",
package.CreateHtmlItem(timeStamp));
}
}
}
The docs explain that "SDL Tridion inserts the code fragment in its predefined method of a predefined class." It looks like this class implements ITemplate and adds some references below (am I missing anything?).
The assembly setup instructions mention at least these dlls.
Tridion.Common.dll
Tridion.ContentManager.dll
Tridion.ContentManager.Templating.dll
Tridion.ContentManager.Publishing.dll
Any other difference between fragment and assembly and how would you choose between the two?
A C# fragment is compiled into an assembly by Tridion when the template is first invoked and after it's been modified. To compile the fragment, Tridion wraps it in some "dungeon dressing" (bonus points for those who know where that term comes from) that:
Uses the Tridion.ContentManager, Tridion.ContentManager.CommunicationManagement, Tridion.ContentManager.ContentManagement and Tridion.ContentManager.Templating namespaces
Makes the Package and Engine available in fields called package and engine respectively
Creates a logger for the C# fragment that is available through a field called log
Adds references to some commonly used assemblies (but does not add a using for their namespaces yet)
Edit: given the other answers it seems many people are not aware of how to accomplish certain tasks in C# fragment TBBs, so I'll document them below:
Import additional namespaces
To import/use additional namespaces into your C# fragment, you need to use this syntax:
<%# Import Namespace="Tridion.ContentManager.ContentManagement.Fields" %>
Note that this will only import namespaces from assemblies that are already referenced by Tridion. There is no mechanism for you to add references to other assemblies explicitly; so if you need a third-party DLL, you will need to add it to the GAC.
Defining custom functions
You can define custom fields and functions in your C# fragment by using this syntax:
<%!
public static string GetDate()
{
return new DateTime().ToString("u").Replace(" ", "T");
}
%>
Defining member fields and (nested) classes
The syntax for defining custom functions also allows you to define nested classes and/or member fields:
<%!
public class MyLittleHelper
{
public MyLittleHelper(string param1)
{
}
}
%>
Frank has explained the difference between the two approaches, but that still leaves the question of how to choose between the two. My personal advise is to never use C# fragments for anything, with only one exception*. As you have found out, there is some dark magic going on in them that I personally do not like. Also, there is so much you cannot do in them that a .NET programmer is quite fond of, such as creating classes.
Putting my personal taste aside, I see only one reason why you would ever resort to C# fragments: if you do not have access to Visual Studio or another tool that builds DLLs. And that is not a very strong argument either: if you want a job done, you should get the proper tools!
*The exception being the C# fragments that Tridion automatically creates for each ITemplate in your assembly, of course.
The main differences between C# code Fragment and .net Assemblies in my point of view are categorized into below high level buckets.
Step-by-Step Debugging
With .net assemblies you could do step-by-step debugging from visual studio where as C# Code fragments it is not possible.
Re-Use or Base Classes
With .net assemblies you could extend ITemplate to create something like BaseTemplate and all your template could extend them so you have common design pattern, where as C# there is no concept of BaseTemplate other than Tridion ITemplate interface.
With .net assemblies you could add common utility classes (often TridionUtilities) and all your templates refer to the same TridionUtilities for common functionality. C# code fragment the utility functions need to be defined within the same TBB and cannot be reused with other TBBs unless you create a class and deploy to GAC.
Easier Upgrade Scans and Maintenance
With .net assemblies it is easier to do any upgrade scans like deprecated APIs/Methods simply referring to new dlls/.net framework. .net assemblies make it easy to identify potential impacts on planning either Tridion upgrades or .net framework upgrades. C# code fragments it is much harder to find the deprecated or any impacts of upgrade.
Developer Friendly
Obviously .net assemblies are developed using Visual Studio (developers love it!) vs. C# Code Fragments in a Text Editor (painful).
When I started back with Tridion 5.3, started with C# code fragments and quickly realized what a mistake I made for not going .net assemblies.
My vote is always .net assemblies and C# code fragments is not even in consideration unless I don't have a choice. lol..
I think the differences indeed are best explained by Frank's answer, as to how would you choose between the two. I normally say, since you are using Visual Studio anyways, always create a .NET Assembly TBB for your code. They offer you a lot more benefits like including 3rd party assemblies, allow for proper coding with classes and methods a lot easier and probably most important, allow for proper debugging (although this last one can be hard to setup depending on where you are, thinking of customer environments, firewalls etc.).
There are for me only two exceptions for using C# Fragments:
The references to classes implementing ITemplate in an assembly, allowing you to use these as separate TBBs
If there is a requirement to manage constants or other hardcoded constants directly from SDL Tridion
Number 2 is of course debatable, but you never can do without configuration properties, for a TBB most of these you can handle using a Parameters Schema, but sometimes it is just a lot easier, to directly write them in a C# Fragment and have that push them to the package for other TBBs to use.
In my training sessions, I usually referred to the following story of the only time I ever choose to use a C# Fragment TBB so far, indicating how much of an exception it is to use them:
I was working at a customer abroad, and my taxi for the airport was leaving in 10 minutes when one of the developers I was coaching asked me a question on how to get a list of items from a Folder in his TBB. I had already closed my Visual Studio and Outlook and was about to shutdown my laptop, but quickly browsed through some of my code samples to find what he needed. Knowing that starting up Visual Studio or Outlook would take a few minutes, I quickly pasted the code in a C# Fragment so he had it for easy reference.
I would never use C# fragments for the sole reason that it makes management of your code quite difficult and you need to manually deploy them. And if you do write your code from Visual Studio, then you should create a .NET Building Block assembly.
A friend of mine is working on a legacy VB6 project. I haven't touched that language in ten years, so I'm pretty rusty. Anyway, is there any kind of reflection API for VB6? Specifically, he needs a way to iterate the properties (and types) of a user-created Class. (In other words, not an external COM object, but an internal "Class Module" as it's called.)
How can this be done?
Jay's answer is the way to go if your project is an ActiveX (ActiveX EXE, DLL, or OCX, as opposed to Standard EXE), and if the classes are public.
However, you mentioned that your friend wants to do this with "internal class modules". I'm not sure if you are referring to private .cls files (classes), or .bas files (modules), but either way, you can only use the TypeLib Information Object Library to reflect on public classes, user-defined types, constants, or enumerations.
You cannot use the library to reflect modules, private classes, or anything else that is declared private.
As a general rule of thumb, you can only use reflection on the things that you can see in the Object Browser when viewing your project's contents from another project. That is, if you compile your project, create a new project, add the first project as a reference, and then view the first project's contents in the Object Browser, anything you can see in the Object Browser can be accessed via the TypeLib Information Object Library. If something is not listed in the Object Browser, then you won't be able to use the TypeLib Information Object Library to reflect it.
VB6 doesn't have any built-in support for run-time reflection or introspection. Using the TypeLib Information Object Library for reflection works for ActiveX VB6 projects because ActiveX projects are compiled in COM components with embedded type libraries, but as mentioned you can only access the data types that are publicly exposed in the compiled component's type library. Using the Object Browser is a quick way to determine what is in the type library because the Object Browser actually inspects the component's type library to populate what you see in the Object Browser, as long as you are viewing the component's contents from a separate project (if you view the component from its own VB6 project, it will display public and private data structures, i.e. everything that is visible in the IDE).
Is this the sort of thing you're looking for:
Visual Basic: Inspect COM Components Using the TypeLib Information Object Library
It's discussed on this thread here on SO: Self Inspection of VB6 UDTs
I've never tried this stuff myself.
I have an C# ASP.NET Web Application Project where all the pages are in the global/default/top-level namespace. (I have no explicit namespace declarations. And when I look at my compiled web application's DLL in Red Gate's .NET Reflector, I can verify that all the classes are in the top-level .NET namespace.) Is there any good, automated way to move all the pages and custom controls into a new namespace, say "MyWebApplication"? Ideally it'd be nice to do it with just Visual Studio, but I'd be open to considering a commercial refactoring tool if necessary.
I thought maybe by setting the "Default namespace" property in the project's Application properties I could get the compiler to implicitly put all pages into the specified namespace, but this appears not to be the case; this "Default namespace" setting seems to make Visual Studio insert explicit namespace declarations into new pages, rather than implicitly affecting the namespace of any existing pages.
If it matters, my immediate motivation here is to try to run a static analysis tool (CAT.NET) on my web application; the tool seems to have a quirk or two with code in the global namespace.
Chris it may look silly as you are ready to pay for the refactoring tool to do it. But consider this:
The namespace is declared in the code-behind file by default as the project/application name. So if you project name is MyWeb the default namespace will be
namespace MyWeb
{
public partical class MyWebPage....
Now this is refered in ASPX page as follows:
<%Page ... CodeBehind="MyWebPage.aspx.cs" Inherits="MyWeb.MyWebPage"
You only need to change these two things to put into effect the namespace migration. And frankly this can be achieved using Find/Replace dialog. Please make a copy of your complete solution and try it!!
Cheers
I'm trying to find a way to generate an enums class dynamically from lookup tables in a database and still have the convenience of a normal class (i.e. intellisense).
I've spent the past few hours trying to figure out how to get a custom BuildProvider to work inside an ASP.NET Web Application. The code works perfectly in a Web Site. I then found an article on MSDN that says
Adding a customized BuildProvider class to the Web.config file works in an ASP.NET Web site but does not work in an ASP.NET Web application project. In a Web application project, the code that is generated by the BuildProvider class cannot be included in the application. For more information, see Compiling Web Application Projects.
Does anyone know if it is possible to generate code dynamically and still be able to 'use' it at design time? Using a web site is not an option. I need to use a web project.
Thanks!!
what is the point of an enum class for a dynamic lookup table? your code references will always be static anyway...
if the initial population of the lookup table is static, make an enum for that and don't reference any other values in the code
If MSDN is saying you can't do it, I'd take another approach. Maybe write a small Console application that writes your Enums.cs file and run it through the "Pre-build event command line". Then, every time you build the web application, the Enums class gets recreated and should be accessible through Intellisense.
Haven't done this myself. Hope it helps.