I'm new to Visual Studio Code (on Mac). We are using it to develop ASP.NET Core MVC applications in C#. When I hit F12 on a symbol, like classes, interfaces or variables, VS Code will jump to the definition of that symbol if the definition exists in the source files, sweet. However nothing will happen if the definition is from an external dependency. If I did this with Visual Studio on Windows, in this situation the default behaviour is jumping to the definition provided by its metadata. Is there a similar way in VS Code to do this, rather than doing nothing in this case? It would be very helpful during development.
The new OmniSharp C# extension for VS Code for >=.NET Core 1.0 now has this feature. If there is no source code available then jump to the definition provided by its metadata. (Since OmniSharp C# extension 1.6.0 for VS Code which I used. But the legacy OmniSharp C# extension for DNX doesn't have this feature)
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 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.
I rebuilt F# with few syntax additions. I was able to tell VS2010 to use them for F# Interactive and for building, but the code editor still claims I'm making errors (even though the project builds just fine).
Is it even possible to change this? If it is - how?
As far as I know, there is no way to change the IntelliSense service used by F# in Visual Studio. The Visual Studio component isn't a part of the open-source release and it has a reference to strongly-signed FSharp.Compiler.dll. I'm not sure if there is some way to trick .NET to load a different assembly instead (specifying bindingRedirect in app.config requires the same strong name). If you find some way, let me know :-) I'd like to use it with my modified version of F# too.
If you want to get some IntelliSense for your modified F#, you can use the F# MonoDevelop plugin. The plugin is open-source and you can change the F# version used in the Services/FSharpCompiler.fs file (see the source on GitHub).
I just installed trail version of Visual COBOL with visual studio 2010 from Micro Focus. I am trying to compile one of my old COBOL programs into .NET assembly. When I compile, it creates .IDY file exension file in the bin floder. I want to decompile assembly to C# code. Is there anyway I can do this?
Thanks..
[Note: post from Micro Focus]
As the previous poster noted, the IDY file is only used to support the debugger.
If this is a managed code project (and you can create both managed and unmanaged (native) code in VS 2010 with Visual COBOL), then you will the assemblies in standard MSIL just like any other .NET language. Bear in mind this is not code that's intended to be human-readable and depends on the Micro Focus COBOL runtime so you can't reverse engineer the code to some other language such as C# (there may also be license agreement issues).
Try renaming it to *.dll, and load it into Reflector. If that fails, MicroFocus is doing something funky and that's not a .NEt assembly. This is probably not unreasonable. The .IDY file could be some form of pcode, which is interpreted by some runtime (that is real .NET code)
The .idy file contains data for debugging, so using reflector on it will not work just like reflector does not work on .pdb files.
I am using the open source Saxon XSLT processor for .NET to execute some 2.0 transforms.
I reference the saxon9api.dll as I would any other dll, and can compile code against this. However Visual Studio does not show any intellisense making the IDE as useful as notepad.
The saxon9api.dll is using the IKVM Java for .NET platform, and I wonder if this is the causing VS a problem. Reflector can inspect the DLL without issue, but I suspect VS is not happy for some reason.
Any ideas?
EDIT:
Surprised that no one else has encountered this behaviour seeing as Microsoft recommends (link is now dead) the use of Saxon in the absense of built in functionality in the framework.
I think I will reword the question to be about assemblies running under IKVM not showing intellisense although I will need to find another IKVM based project to prove that this is the case first...
To make compiling, running and intellisense work in Visual Studio, you need to do the following:
Reference saxon9api.dll, as you already did
Reference IKVM.OpenJDK.Core.dll
Reference IKVM.Runtime.dll (not sure this is needed, but I always include it)
If you are also referencing vjslib, you may run into issues, because it uses a lot of the same namespaces and classnames, leading to ambiguities that can cause Visual Studio's intellisense to get into problems. Perhaps other libraries exist that show the same namespace clashes. In that case, try this on a fresh project first and add the references one by one, starting with Saxon's dependencies first.
After you do this, at least in Visual Studio 2010, 2012 and 2013, you will find that the context-sensitive help is working (image is of VS 2012 with R#):
Note: since this post is old, it may have only applied to Visual Studio 2008 at the time, I have not tested that as I am not using it anyore.