I have created a WPF project in Visual Studio 2017 and it runs without any issues.
However, I noticed that many of the guides online are using a .csproj to perform several tasks. When I tried searching for my .csproj file, I couldn't find one.
Is there something wrong with my project?
This is what it looks like:
The closest thing I have is my App.config files
You can right click the solution then click Unload Project. From there right click again and you will see 'Edit csproj'. That is an easy way to edit it in VS.
The Main() method is created automatically. If you want to provide your own you have to (tested in VS2013 and VS2017):
Right-click App.xaml in the solution explorer, select Properties
Change 'Build Action' to 'Page' (initial value is 'ApplicationDefinition')
Then just add a Main() method to App.xaml.cs. It could be like this:
[STAThread]
public static void Main()
{
var application = new App();
application.InitializeComponent();
application.Run();
}
Related
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
im tring to open a window in wpf app from another file.
ive added it to the main project but i cant run it.
im trying to do something like this:
this(//the main window) = WpfApplication(//other project).MainWindow;
is it possible?
If you've added the the project you need to use to your solution you may also need to add a reference to that project in your original project as well.
This seems like it should be pretty simple but I can't seem to make it happen. Lets say I have an existing project with a user control named uc1. I would like to use this user control in another project. I right-click the project name in the solution explorer and select add>existing item, change the drop down to all files and select the files uc1.xaml and uc1.xaml.vb. This of course adds the files to the project but there is no correlation between the xaml and the code behind file and there is no way to use the control. What is the proper way of doing this?
Reed's answer is a good architectural one. If you plan on creating a control that you will reuse in many projects then it's best to use a control library.
Your original question is valid in some situations though. Say you have some source code from the Internet that you've unzipped to your drive. This project contains a .XAML file and its linked .vb file that you want to add to a project.
As you seen, the Visual Studio Solution Explorer doesn't link the files when adding with the "Add Item" dialog. I think this is a bug. I find that if I reload the project, the affiliation is added.
Here's a workaround I use. I drag the files from Windows Explorer /File Explorer onto the project in Solution Explorer. That works correctly the first time.
This of course adds the files to the project but there is no correlation between the xaml and the code behind file and there is no way to use the control. What is the proper way of doing this?
Normally, you'd add a reference to the other project, and use the UserControl directly.
This allows you to build a single project with your UserControl, and use the resulting assembly (DLL) in multiple projects without duplicating the code.
If you want to reuse your user controls you need to create a new project and choose "Class Library" from the list of available projects. When compiled this class library can easily be used by any number of other projects and solutions simply by adding a reference to compiled DLL created when you build this class library.
Edit: As mentioned in other answer it's "WPF UserControl Library", not simple "Class Library"...
You just need to add the .xaml file and VS should auto add the code behind(nested). I've seen this not work a few times and as #Walt Ritscher said this is probably a bug.
I found simply restarting Visual Studio and reloading my solution worked.
I spend most of my time developing controls for both WPF and Silverlight using the same codebase. To do this I add existing files from one project (say Silverlight) "as links" to the other (say WPF). For minor differences I use preprocessor directives like
#if SILVERLIGHT
...
#else
...
#endif
The code in these blocks is grayed out depending on the type of project you've opened the file from. So if you open your file from Silverlight project (where SILVERLIGHT is defined) the else part is gray and Intellisense doesn't work in it.
In order for WPF part to be processed by IDE (with coloring and Intellisense support) you need to open the file from the WPF project. When you try to do that you get a message box saying that "This document is opened by another project" and when you click OK it displays that file in the context of the Silverlight project (not what I wanted to see). So I have to close the file, navigate to WPF project again and open the file again. This is very, very annoying.
So the question is this: is there some sort of setting or add-on that would make Visual Studio reopen the file from the project where I double-clicked on it instead of showing that stupid message box and showing me that file from the "wrong" project?
This has happened to me about twice in a month now, not in a WPF application. No idea why it happens but in both cases the fix was to Clean the solution, reboot the PC (not just restart Visual Studio) and then build the solution.
You could make this a little easier to work with by using partial classes and multiple files: shared code that is the same for both WPF and Silverlight in a shared linked file, and a separate file for each containing the code specific to one or the other (with identical method/property signatures), each of which is only in one of the projects. Doing this allows both the WPF and Silverlight versions to be opened at once (since they're separate files) at the cost of adding a bunch of extra file management overhead.
Beyond that, get some extra memory and use separate solutions.
It occurred to me, when I had one project containing a linked file of other project under one VS solution. When I tried to navigate to the definition of a method in linked file, VS prompted with a message that this document is opened by another project.
To resolve this, I had to unload the project that owns the original file from the VS solution. After that navigating to method definition in normal time and debug time was not an issue.
Yes this is possible using Visual Studio Shell.
First instantiate EnvDTE80.DTE2 object:
private static EnvDTE80.DTE2 _dte;
public static EnvDTE80.DTE2 DTE
{
get
{
if (_dte == null)
_dte = ServiceProvider.GlobalProvider.GetService(typeof(DTE)) as DTE2;
return _dte;
}
}
and then:
// On Document Opening, close the existing instances.
// This event occurs when you double-click file in Solution Explorer.
DTE.Events.DocumentEvents.DocumentOpening += (s, e) =>
{
if(!DTE.ItemOperations.IsFileOpen(YOURFILENAME))
return;
foreach(Window win in DTE.Documents.Cast<Document>()
.FirstOrDefault(s => s.FullName == YOURFILENAME).Windows))
win.Close();
}
// next; VS itself will call DTE.ItemOperatins.OpenFile(YOURFILENAME);
HTH.
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.