When I try to use an extension method in the Immediate or Watch windows, I get the following error:
{method} is not a member of {class}
I'm using Visual Studio Community 2013 Update 4, but the issue exists on multiple PCs here, running varying versions of Visual Studio 2013 and 2015.
It makes no difference whether the extension methods come from the .NET BCL, or are defined in our project. The code itself compiles and runs successfully; the issue is only in Immediate and Watch.
I tried setting all projects to framework 4.5.1, and using the x86 configuration, without result.
Adding Imports System.Linq at the beginning of the code file makes no difference (which makes sense, as System.Linq is already globally imported (Project properties -> References -> Imported namespaces)).
What else can be done?
In any context where System.Linq isn't imported you can call the extension methods as normal static methods instead. So for example, the following did not work for me in the QuickWatch window (where actualVariables is a List):
actualVariables.Select(x=>x.Identity.DisplayName)
Change it to this form and then it works:
System.Linq.Enumerable.Select(actualVariables,x=>x.Identity.DisplayName)
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'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)
Our company has legacy system that heavily relies on T4 and the employee who architected it is gone. It was running fine for us, however recently some developers upgraded to VS2015. The T4 transformations stopped working for them (with error similar as reported below). It looked at though there were references to Microsoft.VisualStudio.TextTemplating.12.0.dll. They changed the references to '14' and all worked for them. However, the same project shared by other developers on VS2013 no longer worked with error:
Compiling transformation: The type
'Microsoft.VisualStudio.TextTemplating.TextTransformation' is defined
in an assembly that is not referenced. You must add a reference to
assembly 'Microsoft.VisualStudio.TextTemplating.14.0,
Version=14.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a'.
Are you able to run T4 on same project that is opened in both VS2013 and VS2015? One side note, there was a dependent assembly that the old employee made that all the TextTransformations derived from (it also provides helpers that are used in the *.tt files). Unfortunately it used an interface only present in Microsoft.VisualStudio.TextTemplating.Interfaces.10.0.dll, so that old reference is being dragged aroundÎ. Not sure if that is contributing or not. But basically here is the bottom line:
When all devs on VS2013, everything worked and references were:
Microsoft.VisualStudio.TextTemplating.12.0.dll
Microsoft.VisualStudio.TextTemplating.Interfaces.10.0.dll
Microsoft.VisualStudio.TextTemplating.VSHost.12.0.dll
Then when some went to vs2015, the only way to get it to work was to change out the 12.0* dlls with 14.0, but then vs2013 developers ceased to work.
UPDATE
I might not have clarified our complete setup. We have 20-30 *.tt files in a separate project that is included in the solution with the project that will have Text Transformations applied to it.
We have a helper Extensibility.CodeGeneration.dll (this references Microsoft.VisualStudio.TextTemplating.N.dll files as well) that have several static helpers and also base classes that derive from Microsoft.VisualStudio.TextTemplating.TextTransformation.
The 'templates' project that contains all the *.tt files, every .tt file use static methods from our helper dll. It also references all the same Microsoft.VisualStudio. dlls.
In every *.tt file, we have something that looks like this, where AreaTemplate is a class defined in the *.tt file itself and either derives from Microsoft.VisualStudio.TextTemplating.TextTransformation or one of the exposed base classes in our helper dll.
var template = new AreaTemplate { Settings = settings, Area = area, Layouts = layouts };
Write( template.TransformText() );
It was asked in comments how I obtained/used a 'host'. In searching through code we have a few common scenarios (all done inside the helper dll). In each instance, host is of type ITextTemplatingEngineHost.
Case 1:
var dte = (EnvDTE.DTE)( (IServiceProvider)host ).GetService( typeof( EnvDTE.DTE ) );
Case 2:
var hostServiceProvider = (IServiceProvider)host;
Given #3 above, I think I have to reference the Microsoft.TextTemplating dlls (and not just the Interfaces dll) due to the use/exposing of TextTransformation class.
Also, if I change references to in both my 'Helper' and 'Templates' project to 12.0...in vs2015, I get error about 'you must add reference to 12.0'...I have references to that in both applicable (in my eyes) projects...not sure why VS tells me to add it. I tried adding an explicit reference in the *.tt file using
<## assembly Name="$(ProjectDir)..\..\Assemblies\Microsoft.VisualStudio.TextTemplating.12.0.dll" #>
But then I got the error
The type 'Microsoft.VisualStudio.TextTemplating.TextTransformation'
exists in both
'c:\BTR\Source\Assemblies\Microsoft.VisualStudio.TextTemplating.12.0.dll'
and
'c:\Windows\Microsoft.NET\assembly\GAC_MSIL\Microsoft.VisualStudio.TextTemplating.14.0\v4.0_14.0.0.0__b03f5f7f11d50a3a\Microsoft.VisualStudio.TextTemplating.14.0.dll'
It is almost like there is a hidden/implicit reference to the latest Texttemplating already built into VS??
Not sure if our setup was a more complicated way to achieve our original goal, but I don't think I'll be able to unwind it and change if we are doing it the incorrect way.
Given our setup let me know if you think I am stuck or not. I was trying to figure out 'conditions' in MSBuild to help support both Visual Studios but couldn't succeed.
Thanks in advance.
Try changing the reference from "Microsoft.VisualStudio.TextTemplating.12.0.dll" to "Microsoft.VisualStudio.TextTemplating.Interfaces.12.0.dll". Each new version of Visual Studio services will have a new implementation assembly that will implement the previous versions interfaces. To maintain backward compatibility, you should only reference the interface assemblies and not the implementation assemblies. You might have to change the templates if they reference anything not in the interface.
Updated
Wow, so you have a pretty complicated setup and I don't know if you will be able to use it in both versions without changing the code like you did.
I think the main problem is in your helper class, in #3 you said that the AreaTemplate class derives from TextTransformation. TextTransformation is in the implementation dll so it will exist in each version of visual studio. If you helper dll is complied to reference it from 2013 and then you use that dll in 2015 it will not work.
When a T4 template is transformed, the text in the file is parsed into a class, that class is loaded into an app domain(separate from the one visual studio is running in) and the class's TransformText method is called. Since your templates reference your helper class, the helper assembly will be loaded into the new app domain, which will in turn try to load TextTemplating 12 in there too, the app domain will not be able to resolve the 12 reference because you are using VS 2015.
In the other direction when you reference text templating 14 from 2015 and try to use it in VS 2013 you will have the same problem, the app domain will not be able to find TextTemplating 14 because you are in VS 2013 and the 14 dll does not exist.
In the last scenario when you are in VS 2015 and your add a link to TextTemplating 12 in your tt files it is failing because the app domain created to run the template has already loaded the TextTemplating 14 dll then you also tell it to load the TextTemplating 12 dll. This goes back to my posts in the comments when I talked about VS backward compatibility, TextTemplating 12 and 14 have the same TextTransformation class in the same namespace and the runtime can't load them both so you get that error.
Few things you can try:
1) Put the TextTemplating 12 dll in the GAC on the VS 2015 machines. In theory, this will let the T4 AppDomain load both copies of TextTemplating and then VS 2015 would be able to use the 14 version while your tt files and helper dll use the 12 version. Leave the VS 2013 machines the same.
2) Do the same as 1 but in reverse, setup the projects to target 2015 and reference the 14 dll then on the vs 2013 machines GAC the 14 dll, not sure if this will work since the 14 dll might have other dependencies on newer vs assemblies.
3) On the vs 2015 machines figure out a way to do binding redirects for the T4 App Domain so that calls looking to TextTemplating 12 would be resolved to TextTemplating 14. Usually binding redirects are done in the app/web.config files but not sure how you would do them for T4, may have to peek at the code and see how the app domain is created and loaded.
I have faced the same problem and I think I have a solution, which works - use the VisualStudioVersion msbuild property to reference the right version of the assemblies. Something like this:
<Reference Include="Microsoft.VisualStudio.TextTemplating.$(VisualStudioVersion)">
<HintPath>..\Dependencies\Microsoft.VisualStudio.TextTemplating.$(VisualStudioVersion).dll</HintPath>
</Reference>
<Reference Include="Microsoft.VisualStudio.TextTemplating.Interfaces.10.0">
<HintPath>..\Dependencies\Microsoft.VisualStudio.TextTemplating.Interfaces.10.0.dll</HintPath>
</Reference>
Make sure the Dependencies folder has both Microsoft.VisualStudio.TextTemplating.12.0.dll and Microsoft.VisualStudio.TextTemplating.14.0.dll.
Seems to work.
We have a very similar scenario to yours, just a bit more complex because our T4 templates depend on a couple of DSL-Tools packages.
I’ve made some tests and in fact the solution for this problem is to remove any reference to Microsoft.VisualStudio.TextTemplating.12.0 and keep the references to the Interfaces assemblies. Exactly as pointed by Frank. This would make the projects and the templates compatible with both Visual Studio 2013 and 2015.
Unfortunately this doesn’t help in our scenario because DSL-tools projects require references to Microsoft.VisualStudio.TextTemplating.12.0 or Microsoft.VisualStudio.TextTemplating.14.0 because the DirectiveProcessor.tt template generates a class that derives from RequiresProvidesDirectiveProcessor, an abstract class that resides in one of those assemblies (depending on the version of Visual Studio you would want to compile the DSL-tools project with).
I suppose that is one of the reasons why DSL-tools projects are upgraded when you open them with higher Visual Studio versions… But that is a pain because it forces large teams like ours to upgrade Visual Studio all at the same time.
I'm beginning my first explorations into Silverlight RIAs and EF4, but I can't get a project to run right off the templates that ship with VS2010 SP1.
Bear in mind here that what I've done is to install a brand new Windows 7 VM, and then I immediately installed LightSwitch Beta 2. Following that, I added VS2010 Premium, and applied Service Pack 1 to that.
The client portion of the Template app is kicking off three warnings and two errors; the details are posted below. It's looking for a WebContextBase class that it can't find, in code that it generated into Web.g.vb (and Web.g.cs) files. So far this project is entirely generated off the solution template; I haven't added a single line of code to what VS2010 generated.
I've since gotten EF4 to work fine in WinForms projects and Light Switch projects.
What's going on here, and how do I fix it?
------ Build started: Project: EF4Test, Configuration: Debug Any CPU
------ C:\Users\Rob\Documents\Visual Studio
2010\Projects\EF4Test\EF4Test\Generated_Code\EF4Test.Web.g.vb(21)
: warning BC40056: Namespace or type
specified in the Imports
'System.ServiceModel.DomainServices'
doesn't contain any public member or
cannot be found. Make sure the
namespace or the type is defined and
contains at least one public member.
Make sure the imported element name
doesn't use any aliases.
C:\Users\Rob\Documents\Visual Studio
2010\Projects\EF4Test\EF4Test\Generated_Code\EF4Test.Web.g.vb(22)
: warning BC40056: Namespace or type
specified in the Imports
'System.ServiceModel.DomainServices.Client'
doesn't contain any public member or
cannot be found. Make sure the
namespace or the type is defined and
contains at least one public member.
Make sure the imported element name
doesn't use any aliases.
C:\Users\Rob\Documents\Visual Studio
2010\Projects\EF4Test\EF4Test\Generated_Code\EF4Test.Web.g.vb(23)
: warning BC40056: Namespace or type
specified in the Imports
'System.ServiceModel.DomainServices.Client.ApplicationServices'
doesn't contain any public member or
cannot be found. Make sure the
namespace or the type is defined and
contains at least one public member.
Make sure the imported element name
doesn't use any aliases.
C:\Users\Rob\Documents\Visual Studio
2010\Projects\EF4Test\EF4Test\Generated_Code\EF4Test.Web.g.vb(34)
: error BC30002: Type 'WebContextBase'
is not defined.
C:\Users\Rob\Documents\Visual Studio
2010\Projects\EF4Test\EF4Test\Generated_Code\EF4Test.Web.g.vb(65)
: error BC30451: 'WebContextBase' is
not declared. It may be inaccessible
due to its protection level.
Have a look at LightSwitch Beta 2 Readme
There are few know issues with the LightSwitch. From the steps you have described to setup your system I would guess that the problem could be because
"2.1.1 Visual Studio 2010 users or
Visual Studio 2010 SP1 Beta1 users
must install Visual Studio 2010 SP1
before installing Visual Studio
LightSwitch Beta2"
You should try uninstalling LightSwitch Beta2 and then reinstall, and let us know if you get the same error.
Hope this helps.
Include this reference..
System.ServiceModel.DomainServices.Client.ApplicationServices
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.