I have written a code analyzer as part of my Visual Studio Package.
This corresponds to the instructions on this page except that it is part of my existing Package and not a stand-alone analyzer.
The analyzer registers itself to analyze the the SyntaxNode types StringLiteralExpression and InterpolatedStringExpression.
public override void Initialize ( AnalysisContext context )
{
context.RegisterSyntaxNodeAction ( AnalyzeString, SyntaxKind.StringLiteralExpression, SyntaxKind.InterpolatedStringExpression ) ;
}
As described here
By default, live code analysis executes analyzers only for open files in Visual Studio.
This is correct. My analyzer runs on open files.
The same page continues:
Run code analysis manually
In Solution Explorer, click the project.
On the Analyze menu, click Run Code Analysis on Project Name.
Code analysis will start executing in the background. You should see the message
Running code analysis for ... in the Visual Studio status bar towards
the bottom-left corner. Once code analysis completes, the status message will
change to Code analysis completed for . Error list will soon refresh
with all code analysis diagnostic
In this case, my analysis does not run.
I have placed breakpoints in the constructor, the SupportedDiagnostics property get, the Initialize function and the analyze function itself. None of them are entered if I start the code analysis manually via the Analysis menu (or via the context menu in the solution explorer).
Is there some additional condition required to activate a code analyzer for the manual code analysis?
I also encountered this weird issue.
In my case, I used the "wrong" Developer Command Prompt.
I installed VS Build tools after installing VS2017, which also installed the 2nd Developer Command Prompt.
The Start Menu shortcuts of the 2 Developer Command Prompt are as follows:
A: BuildTools (does not work!)
%comspec% /k "C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\Common7\Tools\VsDevCmd.bat"
B. VS Professional (works!)
%comspec% /k "C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\Common7\Tools\VsDevCmd.bat"
I spent all afternoon trying to figure this out! :-(
Related
I have a Continuous Integration Build Running on a BuildAgent which I can not get working properly. I recently changed our codebase to C# 6.0 and changed the projects to ToolsVersion 14.
I did install Visual Studio 2015 on the Build Server (TFS 2012). If I do now check in the C# 6.0 code the build fails on the first project ("$" is unexpected or something")
The BuildTemplate is "DefaultTemplate.11.1"
If I check the log files the build calls the wrong csc.exe (C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Csc.exe)
if I do start the MSBuild/14.0/Bin/MSBuild executable with the project without any switches the Build succeeds. Why does the TFS BuildAgent not use the ToolsVersion and how can I get TFS 2012 to build my Visual Studio 2015 solution
If I add the MSBuildArgument /tv:14.0 it still fails. As it calls th Version 12 of MSBuild which is part of the .NET 4.6 RC Framework which ships with Visual Studio 2015.
Changing the ToolsPath of the MSBuild Activity does get the Build working but spits bullets if I try to run my UnitTest. I get aMissing dlls "Microsoft.VisualStudio.TestPlatform.Utilities.dll" exception. (VS2012 is installed as well on the Build Server).
UPDATE:
I do now get a different error with my unit tests:
TF900548: An error occurred publishing the Visual Studio test results.
Details: 'Method not found:
'System.Collections.Generic.IEnumerable<System.String>
Microsoft.VisualStudio.TestPlatform.Utilities.InferSettingsHelper.MergeRunSettingsAndFindCompatibleSources(Microsoft.VisualStudio.TestPlatform.ObjectModel.Architecture
ByRef,
Microsoft.VisualStudio.TestPlatform.ObjectModel.FrameworkVersion
ByRef, System.String, System.String,
System.Collections.Generic.IDictionary`2<System.String,System.Collections.Generic.KeyValuePair`2<Microsoft.VisualStudio.TestPlatform.ObjectModel.Architecture,Microsoft.VisualStudio.TestPlatform.ObjectModel.FrameworkVersion>>,
System.Xml.XPath.IXPathNavigable, System.String ByRef)'.'
For those of us not living inside build templates every day here's the steps that got it working for me:
First find the template associated with your build (if you already know where to find it skip a couple steps).
Just right click the build definition and select Edit build definition
Select the Process tab and you'll see the name of the template (quite likely to be DefaultTemplate if you haven't customized it). On the far right click Show details to see the path for the template.
Go to the Home tab under Team explorer and click Source control explorer
Find the template file and double click to edit it. It should come up in a graphical view like this. Scroll till you find Run MSBuild for Project
Click on this item which will immediately bring up properties
Click on the little icon on the right - don't try and type it in because it'll probably explode and crash Visual Studio.
Enter IN QUOTES the following "C:\Program Files (x86)\MSBuild\14.0\bin"
NOW FOR THE MOST IMPORTANT PART
For me the Run MSBuild for Project was in TWO places.
So I just repeated the above steps in both places, and then after I checked in the .xaml file my build FINALLY worked fine.
You may need to recycle the agent / controller from within the TFS tool.
Edit template change msbuild activity ToolPath to "MSBuild/14.0/Bin/MSBuild"
See answer by Marson.
Using the TfvcTemplate.12.xaml build process template with the /tv:14.0 Build argument worked for me.
use msbuild aruguments /p:VisualStudioVersion=14.0
I am getting the following error when running my build on Visual Studio Online (using the built-in Build Controller):
C:\Program Files
(x86)\MSBuild\14.0\bin\amd64\Microsoft.Common.CurrentVersion.targets
(3962): Could not copy
"d:\a\src\MySolution\MyProject\Trunk\packages\Microsoft.Data.Edm.5.6.4\lib\net40\Microsoft.Data.Edm.xml"
to "..\Build\bin\Release\Microsoft.Data.Edm.xml". Beginning retry 1 in
1000ms. The process cannot access the file
'..\Build\bin\Release\Microsoft.Data.Edm.xml' because it is being used
by another process.
It is never the same file either but it seems to always be either an xml or dll from the packages folder.
EDIT: I'm not sure if it is worth mentioning, but I do have multiple workspaces and multiple build definitions using this repository.
I found the problem. Completely unrelated to the error above.
I went into the msbuild log files and found this:
Failed to produce diagnostics extension's config for
MyRole\diagnostics.wadcfgx. Error : Could not find a part of the path
'd:\a\src...\MyRole\diagnostics.wadcfgx'. Done Building Project
"d:\a\src...\MyCloudProject.Cloud.ccproj" (Publish target(s)) --
FAILED.
I was missing a file in source control.
I do wonder why this error did not bubble up into my build summary. And where did that initial error come from?
I am using TFS with Using Visual Studio 2013 and have been able to work around this issue by closing all open documents that I want to check-in (seems VS locked itself out) and/or resolving conflicts. The error message is sufficiently vague so as to be useless as to the actual cause of the check-in failure.
Update 02 November 2016:
I'm not sure why VS 2013 and TFS don't play nice together via the Team Explorer Check-in Pending Changes button, but it consistently fails to launch the conflict resolver, a key piece of the check-in process.
The following works for me on VS 2013 and TFS hosted on a SQLServer Express 2014 database:
1. Launch the Source Explorer: Team Explorer tab -> Source Explorer
2. Navigate to your solution repository
3. Then proceed to do the following for each project that you want to check in:
a. Right click project
b. Check in pending changes
c. Resolve conflicts and repeat steps 3a and 3b until no pending changes remain for the project
I am using Visual Studio 2013 and Team Foundation Server 2013. I have these, as well as the Build Controller/Agent, running on my personal computer, called "FUSROHDAH".
My goal is to take a build generated by the TFS Build Agent and open it for debugging in Visual Studio, and have it leverage the source indexed PDB to access the source code from the TFS source control system so that I can step through the code. I have studied several informative articles about PDB's and source indexing, including:
Ed Squared's article on Source Server and Symbol Server Support in TFS 2010
John Robbins' article about PDB files
I also watched John Robbins' very excellent video on WintellectNOW which discussed a lot of the nuances of setting up the symbol server, source indexing.
However, despite several days of hair pulling, I haven't been able to get this working yet.
I've set up TFS for continuous integration. Here are my settings:
In Build Definition->Build Defaults, I have set Staging Location to "Copy build output to the following drop folder (UNC path, such as \server\share)":
\\fusrohdah\builds (this equates to c:\builds on my machine)
Build Definition->Process Template Settings:
Path to Publish Symbols: \\fusrohdah\symbols\ (this equates to c:\symbols on my machine)
I notice that the Default Process Template in TFS 2013 looks different from the articles discussing TFS 2010. In Ed Squared's article, there is an option for "Index Sources". In TFS 2013, this setting is gone, and in the instruction text, it says "Specify the path to the symbol store share. When this value is set, source indexing is a part of the build." So I assume that I have source indexing running on my builds, by simply specifying this location.
So I take a simple console application HelloWorld and I perform a series of changes and check-ins. I observe the builds are published to the builds folder as I would expect, with an EXE and PDB file side by side.
So I want to take an older build and debug it in Visual Studio, and step through source code obtained from the TFS source indexing. I open the EXE in Visual Studio and hit F11 to launch the console application and begin stepping into the code in the Main() procedure. But, when this happens, I get this message:
--------------------------- Microsoft Visual Studio
--------------------------- Source file: C:\builds\2\LocalTestProject\HelloWorld\src\HelloWorld\HelloWorld\Program.cs
Module: C:\builds\HelloWorld\HelloWorld_20140722.6\HelloWorld.exe
Process: [6016] HelloWorld.exe
The source file is different from when the module was built. Would you
like the debugger to use it anyway?
This seems to be the crux of my problem. My understanding is that when Visual Studio reads my PDB file, it should execute TF.exe to obtain the correct version of the source code from TFS, and it seems to be failing to do this. I used PDBStr.exe to look at the PDB file published by the build, and nothing seems amiss:
c:\builds\HelloWorld\HelloWorld_20140722.6>pdbstr -r -p:helloworld.pdb -s:srcsrv
SRCSRV: ini ------------------------------------------------
VERSION=3
INDEXVERSION=2
VERCTRL=Team Foundation Server
DATETIME=Tue Jul 22 23:04:51 2014
INDEXER=TFSTB
SRCSRV: variables ------------------------------------------
TFS_EXTRACT_CMD=tf.exe view /version:%var4% /noprompt "$%var3%" /server:%fnvar%(
%var2%) /console >%srcsrvtrg%
TFS_EXTRACT_TARGET=%targ%\%var2%%fnbksl%(%var3%)\%var4%\%fnfile%(%var5%)
SRCSRVVERCTRL=tfs
SRCSRVERRDESC=access
SRCSRVERRVAR=var2
VSTFSSERVER=http://fusrohdah:8080/tfs/DefaultCollection
SRCSRVTRG=%TFS_extract_target%
SRCSRVCMD=%TFS_extract_cmd%
SRCSRV: source files ---------------------------------------
C:\Builds\2\LocalTestProject\HelloWorld\src\HelloWorld\HelloWorld\Program.cs*VST
FSSERVER*/LocalTestProject/HelloWorld/HelloWorld/Program.cs*18*Program.cs
SRCSRV: end ------------------------------------------------
I observe in the Output window that Visual Studio thinks it has successfully loaded the symbols when I'm debugging my EXE. I do not see a message indicating that it ran TF.exe, however, so I believe it is failing to run this to obtain the source.
I did verify in Visual Studio that I have "Enable Just My Code" UNCHECKED, and "Enable Source Server Support" CHECKED, along with "Print Source Server diagnostic messages to the Output Window".
Question: how do I know if Visual Studio is attempting to run TF.exe to obtain source code from TFS like I would expect?
Aside from that, I'm not sure if my problem is with the build configuration, symbol server/source server configuration, or my approach to attempting to debug using the aforementioned pieces. I will pledge fealty to the wizard who can illuminate my path for me!
Have you tried removing the build server working directories before debugging ? If a debugger can find the files denoted in SRCSRV on disk it will take precedence over getting them with tf.exe (even if they are the wrong version match). Only if it can't find the files on disk or in cache, it will try reference the source server. Because you are performing this on the buildserver, the locations denote a later version of the sources.
VS2012 seems to remove the popup window for TFS check-ins that was in VS2010. It now seems to take over the team explorer tab in my sidebar, and buries the important things - like which files I've changed. Is there any way to return to a normal popup window for check-ins in VS2012?
For me, the best solution is based on iSid's answer: to add an external tool that pops up the old dialog.
You can do this from Visual Studio: TOOLS -> External Tools… -> Add, with the following values:
Title: Checkin (or any name that should be displayed in the menu)
Command: C:\Program Files (x86)\Microsoft Visual Studio 11.0\Common7\IDE\TF.exe (this is the default VS install location on Windows x64)
Arguments: checkin
Initial directory: $(SolutionDir)
Here is a screenshot:
You can invoke from TOOLS -> Checkin (or even assign a keyboard shortcut to Tools.ExternalCommand* as described here) and enjoy the old goodies with a new style:
Note that this won't work if a solution is not opened, because of the $(SolutionDir) variable. To workaround this, you can hard-code the path to your workspace instead.
Additionally, tf.exe can be invoked with 'shelve' argument, which will show the old-style shelving dialog.
Use tf checkin command from Visual Studio command prompt and you will get the same old checkin window.
While the Pending Changes window is merged within the Team Explorer, the Solution Explorer allows filtering by what is pending to be checked in. In addition Open Files filter could also be applied. When the Pending Changes filter is applied, all or some of the files could be selected and right clicked and then there is an option to do the check in. That command takes directly to the Team Explorer in Pending Changes view. See below...
Another method is to use the Productivity Power Tools. This extension adds Windows shell integration so you can perform most of your TFS commands directly from within Windows without even having Visual Studio open. The Power Tools uses the old style windows when used from within Windows shell.
I think the easiest solution is just docking the Team Explorer tab as tabbed document (using the right-click menu). That way it will be equivalent to the popup dialog.
I have created a custom check-in policy as given in the link below:
http://msdn.microsoft.com/en-us/library/bb668980.aspx
I followed the steps as explained by the article. Everything works fine. My doubt is - Is it possible for me to debug the code while check-in the code?
Consider I want to know what are the methods are called inside the CheckForCommentsPolicy class as stated in article or I have added some business logic which needs to debugged. Which process do I have to attach? or Do I have to follow any other approach for debugging?
Is it possible to debug? Kindly help me out.
Thanks in advance
While MrHinsh's method will in fact work I found that there is an even easier way to debug and would like to recommend that.
If you go to the properties of your checkin policy class project and look under the debug tab you will find a section for Start Action. Select to "Start external program" and browse to where you have visual studio installed.
for instance
C:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE\devenv.exe
With this in place and the proper registry keys for loading the policy DLL from your debug folder all you need to do is hit Run and a second copy of VS 2010 will load up and you can debug your class without doing the Debug | Attach to process steps.
Yes. You need to have two copies of Visual Studio open. One had your solution open and the other for running the code.
You need to select "Debug | Attach to Process..."
Figure: Open the Attach to process dialog
You can then see all the available process on your computer and you should see the other instace of Visual Studio (this is the one you will use to run your checkin policy).
Figure: Attach to the devenv.exe process
This will allow you to debug the instance of your Check-in Policy running in the copy of Visual Studio you just Attached to.
I got the answer:
http://msdn.microsoft.com/en-us/magazine/cc163320.aspx#S3