Using Ninject and MVVM-Light in a Class Library DLL. When I free up all Views that call for the DataContext
<UserControl.Resources>
<vm:ViewModelLocator x:Key="ViewModelLocator"/>
</UserControl.Resources>
<UserControl.DataContext>
<Binding Path="DataViewsViewModel" Source="{StaticResource ViewModelLocator}" />
</UserControl.DataContext>
...it appears to NOT release the ViewModelLocator.
Using ANTS Memory Profiler, the only references remaining are to the ViewModelLocator.
I suppose more detail is in order, and would welcome any guidance on what information is most beneficial to resolve this issue. I am learning on the fly here :).
What I'm trying to accomplish is the complete Cleanup of an instance of a class object so that when a new one is instantiated it will start completely new.
p.s. this Class Library is our way of adding WPF into an MFC C++ application. We are calling up "controls" as needed and want to completely cleanup or dispose when no longer needed.
Related
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.
I have an old asp.net that I'd like to move from a Windows environment to Linux.
The application has an old Web.config, a bunch of dlls and an App_code folder.
Can you point me in the right direction to getting this working?
What I've tried so far:
dotnet publish -c Release -o /var/www/blah
But this complains:
app_code/Rewriter.cs(3,14): error CS0234: The type or namespace name 'Web' does not exist in the namespace 'System' (are you missing an assembly reference?
I read that System.Web doesn't really exist anymore.
My question is, can I reference some kind of build environment that will build and deploy this old-style application? Or so I need to port all the code?
Migrate any business logic to classes, so you can reuse it. The more code you can move to classes (or even class libraries), the easier it will be. Then create a new ASP.NET core application and rebuild the UI bits.
The hardest part is if you have a lot of spaghetti because you over-utilized the event methods in your code behind files. You may end up with a lot of refactoring, but the idea is to keep it working as is, but with the actual code outside of the ASPX pages. Once your event handlers look more like this
public void THisButton_Click(e as EventArgs)
{
OtherClass.Method();
}
you will find it much easier to migrate to MVC, which is how you will want to design the UI with for ASP.NET Core.
If this is not making sense, let me know, and I can see if I can point you to some information that helps.
I've got two questions here. The first one is just specific and another one is more general, but is a source of the first one.
So, my specific problem: I want to use Encryption (actually, Hashing) algorithms with using System.Security.Cryptography namespace (for instance, SHA256Managed class).
I found out that (happily) Xamarin has implemented those in System.dll.
But it is not portable and obviously can not be used from Core application directly.
But I've also found another great project -- PclContrib -- which allows you to do that. But, unfortunately, they don't have the implementation for Touch and Android. (However, that still works great for Desktop (Web) and Windows Phone, plus, still can be included into Core (as it uses portable project)).
Anyway, to solve that nicely, I've decided to create some base class for the encryption methods and then override core methods which require the custom dll (for any custom system).
The way I did it (at least, trying to do) was:
Defining virtual method in Core App base class:
public virtual IEncryptionProvider CreateEncryptionProvider()
Overriding Core App class in Touch project with overriding CreateEncryptionProvider (which creates an instance of TouchEncryptionProvider class instance).
Core:
public class App : MvxApplication
Touch:
public class AppTouch : App
Launching it in Touch setup.cs:
protected override Cirrious.MvvmCross.ViewModels.IMvxApplication CreateApp (
{
return new AppTouch();
}
But, that does not work for me. On startup I've got this exception message in log:
"Exception masked KeyNotFoundException: Could not find view for Mynamespace.Etc.LoginViewModel", which works fine when I do new App() instead. I am not sure if that message shows actual problem (as before it was saying the same even that was a problem with some third-party dll, unrelated to views at all). But speaking shortly, that's just a primitive inheritance of App : MvxApplication, but placed not in Core but Touch project.
So, does it requeire some more custom initialization for such situations or do I miss something else?
And, actually, more general question is how should I build such Multiplatform approaches? Actually, now I've got similar problem with HttpUtility.UrlEncode, which I would want to use in my Core project.
What is the MvvmCross "philosophy" to handle such situations?
Thank you.
For the 'viewmodel not found' problem, this is caused because mvvmcross by default only looks for viewmodels in the Assembly containing your app.
If you want it to look in other assemblies, override ViewModelAssemblies in Setup.cs - see how this done in, for example, MvvmCross - structuring shared View Models and Views
For general multplatform approach, please read questions and answers like:
Platform-specific IoC in MVVMCross
Instantiation of ViewModels and Service classes
Please also remember you don't have to use PCLs - if you prefer to use file-linking between multiple platform-specific core projects, then you can of course use this approach.
Finally, please also try to ask one question per question - I find it makes stackoverflow work better for users and with search engines too. If you need to link questions, then you can just add a hyperlink reference - stackoverflow then marks them as related.
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.
is there any way to map 2 Models once in my application ( Mapper.CreateMap()) for example in global.asax and then wherever necessary just call Mapper.Map() in codes ?
Yes you can, and in fact that's the recommended way to configure AutoMapper. Creating the initial mappings is the (relatively) expensive part of AutoMapper, so you want to do it only once.
As you suggest, Global.asax is a good place to do it. Although it's a good idea to put it in a separate class, for example Bootstrapper, that the Application_Start method calls into, such that this class and method can also be called from your unit tests.
From the AutoMapper docs:
Where do I configure AutoMapper?
If you're using the static Mapper method, configuration only needs to happen once per AppDomain. That means the best place to put the configuration code is in application startup, such as the Global.asax file for ASP.NET applications. Typically, the configuration bootstrapper class is in its own class, and this bootstrapper class is called from the startup method.
See also this question, which has some good ideas including a suggestion from Jimmy Bogard, who wrote AutoMapper.