I see that MS has documentation on how to implement nesting projects when implementing new project types. While this looks do-able, I'd rather not write and maintain my own VS extension if I can avoid doing so. Is there any "generic" project type already implemented by some extension that will allow project nesting? The idea would be that the parent project does nothing but include its children and allow building, adding references, etc.
Managed Package Framework for Projects is for Visual Studio 2013 and includes "a project system that supports nesting" (see the NestedProject sample). I have not tried it myself, though I did look through it a while back (the VS 2010 version) and it has thorough documentation.
It may or may not be as extensive as what you are looking for. From the overview in the documentation:
Creating a new project type in Visual Studio is complex task. Using MPF_Proj is a good starting point for creating custom project types in Visual Studio written in managed code but there are limitations that would have to be considered before using the framework.
MPF_Proj is not a .NET library. It is rather a framework of source files (classes, utilities etc.) that can be included in a VSPackage project.
Related
I'm learning F# and I'm just trying to build Animate a pendulum program.
Here's the code:
https://rosettacode.org/wiki/Animate_a_pendulum#F.23
As far as I understand, VS 2019 doesn't support WinForms in F# (maybe, I'm wrong), so I have error messages, trying to copy/paste that code:
What should I do?
Thanks a lot !
If you're looking to use Winforms on .NET core, you'll need to do the following in your project:
Open the project file (double-click on the node in Visual Studio)
Change the Sdk to Microsoft.NET.Sdk.WindowsDesktop
Ensure you have this OutputType: <OutputType>WinExe</OutputType>
Add the following property to the top-level PropertyGroup: <UseWindowsForms>true</UseWindowsForms>
There won't be a visual designer to use, but you should have access to the APIs.
Unfortunately, there is no Winforms designer in Visual Studio 2019 for F# projects of any type, and Winforms can only be easily accessed (as far as I know) in .Net Framework (NOT .NET Core) projects they can be accessed as per #Phillip Carter's answer.
However you can still make Winforms programs easily by manually adding the references to your .NET Framework project, or (more easily) by manually compiling with the F# compiler, fsc.
The Fast Way
The easiest way to do this is simply compile the source code with the F# compiler from a single source file with fsc.exe. The F# compiler will automatically resolve dependencies for things like System.Windows.Forms and a lot of other commonly used namespaces. You can also provide lots of compiler directives for requiring other resources as well.
Example using VSCode, with various extensions:
Another Way
Start a new F# console .NET Framework project (don't pick .NET Core).
Right click on "References" in the Solution Explorer and click "Add Reference..."
Under assemblies, look for "System.Windows.Forms," select it...
And also select "System.Drawing" and then hit OK
Now you have access to both of those namespaces.
Before you run the project in Visual Studio, you should replace
[<STAThread>]
Application.Run( new PendulumForm( Visible=true ) )
with
[<STAThread;EntryPoint>]
let main _ =
Application.Run( new PendulumForm( Visible=true ) )
0
This way you (and VS) know where main actually is. It's not necessary for this small of a program to actually run it, but as your projects get larger VS will complain more about where things are located in your project.
I work with Xamarin.Forms in Visual Studio since a few years, and updated my IDE recently (VS v. 16.3.7). Now I realized something is missing: the Shared Project option.
When i go through the Wizard to create a new project the question if I want to use Shared Project or PCL(or NetStandard) is now missing (see screenshot below from VS 2017)
I do know that you can still create a Shared Project and add an iOS and an Android project manually, but this is just too cumbersome. My question really is: Is there a reason why Microsoft went on to push the PCL/NetStandard above the Shared Project strategy?
I am specially confused about this decision since already back in 2016 #miguel.de.icaza declared his favorite option (for most cases) was the Shared Project strategy:
https://tirania.org/blog/archive/2016/Jan-22.html
For me, the PCL is just too cumbersome for most uses. It is like using a canon to kill a fly. It imposes too many limitations (limited API surface), forces you to jump through hoops to achieve some very basic tasks.
I have installed VS 2017 15.9.14, on this version, Portable Class Libraries (PCLs) are deprecated. You could use .NET Standard instead. On VS 2019, the default is .NET Standard.
On Microsoft document, MS recommend .NET Standard 2.0 libraries over Portable Class Libraries.
For more, please refer to the MS docs. https://learn.microsoft.com/en-us/xamarin/cross-platform/app-fundamentals/code-sharing
My question really is: Is there a reason why Microsoft went on to push the PCL above the Shared Project strategy?
For MS announcement, PCL is deprecated, you could not find that when you create the project.
You could create the Shared project by File > New > Project > Shared Project template.
For more details, you could check the link below. https://learn.microsoft.com/en-us/xamarin/cross-platform/app-fundamentals/shared-projects?tabs=windows
Updated:
Is there a reason why Microsoft went on to push the >NetStandard< above the Shared Project strategy?".
For the old version of VS 2017, .Net Standard is an option of Shared Project strategy.For the latest version of VS, MS use .Net Standard as the default for Sharing Strategy.
Is there any doc where MS states why Shared Project is now deprecated/not available in the Xamarin.Forms project wizard?
PCL is deprecated. Shared Project is still in use, in my answer, I provide the second link about how to create the shared project.
Summarizing and adding to the answer by #WendyZang-MSFT:
I started a project using the Shared Project strategy around 4 years ago, and until now i have not found any issue/problem specific to it that would make me consider moving to .Net Standard.
Recently i went into the trouble of localization, and even that was possible using Shared Project without much hassle.
As mentioned above, after i saw that the latest version of Visual Studio 2019 was not offering the possibility of creating a Xamarin.Forms App as a Shared Project i got a bit worried thinking that i should migrate my solution. But the time hast passed by, and i just realized that MS encourages the use of .Net Standard, but Shared Project remains also a valid approach.
I am struggling with creating NuGet packages. I am using Visual Studio 2017 Community edition.
I have seen a couple of videos that show a "Pack" option on the menu when right-clicking the project in Solution Explorer. However, I do not have that option. Is this one of the features in the other (non-Community) versions of Visual Studio? I believe I have also seen a "create NuGet package on build" option mentioned somewhere. I cannot find that either.
I have tried various ways of using nuget, dotnet, and msbuild from the command line(s), but haven't had much success. Very frustrating.
Any help is appreciated.
If you really want to use Visual Studio, I would recommend installing an extension that helps you with that problem. For example, this one. The options people have in videos depend on the extensions they have installed. For you, it is the same.
Alternatively, just use the command-line tooling for this as explained here or for .NET Core here or here.
dotnet/msbuild pack is only available for SDK-style projects, but I believe works for all versions of Visual Studio, as well as on the command line. .NET Core introduced these SDK-style projects, which can be identified by <Project Sdk="Microsoft.NET.Sdk">. If your project (.csproj if it's a C# project) doesn't have the Sdk property or import Microsoft.NET.Sdk in either of the two other ways, then it's not an SDK style project and doesn't support packing in this way. Another obvious difference between the two styles of projects is that SDK projects are only a few lines long from the new project template and don't list files in the project, whereas old style projects are typically a full screen long, even from a new project template with only a single class file, and it does list individual files in the project. If you want to continue with this project type, you'll need to use nuget.exe pack and you'll probably want to create a .nuspec file to define some of the package metadata.
However, using SDK style projects is the future, it just takes time for all of Microsoft's existing project types to migrate. It's much simpler to use, so personally I would avoid old style projects unless you're using a project type (like ASP.NET, not ASP.NET Core) that doesn't support it.
All of this is confusing for anyone new to the .NET ecosystem. My recommendation is 1. when you install Visual Studio, when making your workload selections, make sure in the component list that .NET Core is selected, whatever the newest version of .NET Core that is available at the time of installation. When creating a new project in Visual Studio, always select the .NET Core version, or .NET Standard version of any new project template, even if you want to target the (Windows) .NET Framework, in which case you edit the .csproj and change <TargetFramework>netstandard2.0</TargetFramework> to <TargetFramework>net45</TargetFramework>, although I would recommend multi-targeting possible by adding a s to the element name and using a semi-colon separated list: <TargetFrameworks>net45;netstandard2.0</TargetFrameworks>. So, avoid the "Class Library (.NET Framework)" template, instead use "Class Library (.NET Standard)" and then change the target if you have to.
#zivkan led me down the right path. Changing my project types to .Net Core from .Net Framework made all the options I mentioned in my original post available. No extensions were needed.
My .Net Core class library project now has the Pack and Publish options available on the project's context menu. In addition, there is a another tab (Package) on the project properties page. On that page there is a "Generate NuGet package on build" option along with version, name, tags and other properties.
I have done much .Net framework development, but have been ignoring .Net Core and the newer options. I guess I need to dig in and learn about them.
I'd like to integrate my own custom language in Visual Studio.
I'd like to have:
Syntax highlighting
invoke a custom compiler, producing source files in another compilable language. These shall be compiled in a second phase.
some simple tools like rename (not text based, so that a local variable is only renamed within scope), find code lines that reference this function/variable etc.
Intellisense (code completion, suggest members, types etc.)
Is there a way to achieve this without too much effort?
I already discovered Xtext (limited to a subset of antlr3) for eclipse, but need a similar tool based on antlr4 for visual studio?
Check out the Extending Visual Studio chapters in MSDN, especially
Language Services
Projects and Solutions
Editors
There are a few other blogs and tutorials on these topics as well:
CodeProject
ANTLR and MyC
And a few language services are open source and provide a great example:
IronPython
IronRuby
ASP.NET Web Stack
I'd like to get started with the Visual Studio 2010 SDK and creating integration packages. All I would like to do for now is provide a new project type and language service. However, I don't know how I should design it...
The package will provide an editor for a programming language that compiles for x86 or ARM processors. The problem is that there are a few language differences depending on which processor you're developing for. I'd rather not have a separate project type for each architecture, however. Preferably, the programmer chooses the architecture when they create the project and the package automatically loads up the specific parts such as the correct language service, configuration settings, and whatever custom tools and dialogs are associated with that architecture.
How would I go about doing this? I've read about "flavored projects", but I don't really understand how to implement them. Is that what I need?
A couple of points to note to get you headed in the right direction:
The interfaces for a language service to hook into the editor have completely changed for VS 2010. I would recommended asking questions on the VS Editor Forum where all the devs for the core VS editor hang out for the speediest answers since the documentation and samples are still incomplete at this point. (There is a compatibility layer to support "old" language services, but you'd be better off just using the new interfaces since you're starting from scratch.)
A "flavored project" (referred to in the docs as a Project Subtype) is a way to add/remove functionality from an existing project system. For example, there is are project flavors for Web Projects, WPF, Devices, Database, etc.... on top of CSProj and VBProj. In these cases C# and VB are the "base" project systems and WPF, Web, Database are flavors that extend the base C#/VB project systems. Since you have a custom language, you should implement your own base project system. Your best bet for starting from scratch would be to build something based off the MPFProj source library.
I'm working on something very similar -- here is my starting point:
http://blogs.msdn.com/noahric/archive/2010/02/15/markdown-part-4-outlining.aspx
It's a very nice example of how to implement an editor extension.