What is wrong with this junction command? - windows-8

I want to make a junction: junction.exe c:\Program Files (x86)\Microsoft Visual Studio 11.0 d:\Programs\Microsoft Visual Studio 11.0
Every time I try, I get the same three junction usage tips. I am using Windows 8, and running cmd under administrator privileges, and have removed the read only checkbox from the program files (x86) folder. When I type junction.exe c:\link c:\link2 it works like a charm. What am I doing wrong?

Just a quick oversight. Nothing major.
When using Spaces like " " in Commands, you must put them in quotation marks otherwise the system reads it as a new line (or some such).
Here is the command you need;
junction.exe "c:\Program Files (x86)\Microsoft Visual Studio 11.0" "d:\Programs\Microsoft Visual Studio 11.0"
As you can see each file path is encapsulated with Quotations making it read as 1 line.
You should be good to go now dude!

Related

MSBuild looking in wrong place for Microsoft.VisualBasic.Core.targets

I am setting up a new TeamCity build agent. Several build configurations that run perfectly well on the existing agent are failing on the new agent, with errors like this (whitespace added for clarity):
[22:14:32][someproject.vbproj]
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\bin\Microsoft.VisualBasic.CurrentVersion.targets(322, 5):
error MSB4019: The imported project
"C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\15.0\bin\Roslyn\Microsoft.VisualBasic.Core.targets"
was not found.
Confirm that the path in the <Import> declaration is correct, and that the file exists on disk.
Note the path on line three after "The imported project". The error is correct; the folder does exist but the file does not exist there. However the Microsoft.VisualBasic.Core.targets file does exist at a slightly different path
C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin\Roslyn\Microsoft.VisualBasic.Core.targets
Is there an easy fix for this, perhaps a registry entry telling MSBuild where to look?
Cause
On your machine, there are two copies of VS 2017 installed, Professional edition and the raw Build Tools.
You didn't install VB bits for Professional, while did that for Build Tools.
TeamCity prefers MSBuild from Professional edition.
Combine all above, the issue happened.
Fix
You should either force TeamCity to use MSBuild from Build Tools, or add VB to your VS Pro installation.
Reference
https://blog.lextudio.com/the-rough-history-of-msbuild-cc72a217fa98

Visual Studio automatically renames external tool path

I am trying to set some external tools paths in Visual Studio 2017 and for some reason, certain entries get automatically renamed. Under
Tools > Options > Projects and Solutions > Web Package Management > External Web Tools
I am trying to enter $(VSINSTALLDIR)\Web\External but after clicking [OK] on the Options dialog, this then gets renamed to $(VSInstalledExternalTools).
I made a small MSBuild script to test the values of each of these variables. This included the following message statements:
<Message Text="$(VSInstallDIR)\Web\External"></Message>
<Message Text="$(VSInstalledExternalTools)"></Message>
The first one outputs "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Web\External" whereas the second outputs an empty string. This is breaking my build process, but I cannot figure out how to resolve.
...Hard to say:
But please use $(VSINSTALLDIR)Web\External instead of $(VSINSTALLDIR)\Web\External.
The latter one equals: C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\\Web\External
Line6: Result of $(VSINSTALLDIR)\Web\External using \\
Line7: Result of $(VSINSTALLDIR)Web\External.
I think the \\ causes this issue. Hope it helps.

Use .wid files with Visual Studio 2017

I have created a Setup Project with Visual Studio 2017 Professional (.vdproj file). I would like to use a Password Dialog as suggested in this page:
https://www.codeproject.com/Tips/659367/Password-Dialog-for-Visual-Studio-Deployment-Proje
This tutorial has been written for Visual Studio 2012 and it's working great, putting the file VsdUsernamePasswordDlg.wid into this folder:
"C:\Program Files (x86)\Microsoft Visual Studio
10.0\Common7\Tools\Deployment\VsdDialogs\1033"
But I can't find the right place to put this file to use it with Visual Studio 2017.
EDITED 09.10.2017
I followed the instructions given by PhilDW but when I try to compile the Setup Project I get this error: ERROR: No such interface supported.
I can't see the Password Dialog among the possible choices:
They are in:
C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\Common7\IDE\CommonExtensions\Microsoft\VSI\bin\VsdDialogs\1033
on my system. If you cannot find any .wid files at all it's probably because the installer project extension is a separate add-in, from here:
https://marketplace.visualstudio.com/items?itemName=VisualStudioProductTeam.MicrosoftVisualStudio2017InstallerProjects
A .wid file is basically a merge module that gets included into the MSI file, and the .wid file in that CodeProject article is just one of the standard edit dialogs that has the password bit set in the attributes of the control. In other words you can achieve the same result in this way:
Choose the additional dialog you want to install, and in this example I will use TextBoxes (C). Build the MSI file.
Open the MSI file with Orca, and go to the Control table. Click on the Dialog heading to sort, then look at the CustomTextC dialog entries. Edit2 and Edit4 will be the two password entries (because Edit1 and Edit3 are usernames in this example). The Attributes value will be 7, change it to 2097159, because you are just adding the value here that makes it a password control:
https://msdn.microsoft.com/en-us/library/windows/desktop/aa368042(v=vs.85).aspx
Save your MSI file.
So in that article the author copied one of the TextBoxes .wid files, opened it with an MSI file editor such as Orca, went to the Control table, made the changes I just made, then saved it as a new .wid file. You can do exactly the same thing if yoi don't want to edit your MSI file.
To complete the answer from PhilDW I write here the solution to use .wid in .vdproj projects in VS 2013 and 2017. You have to put them into:
Visual Studio 2017
C:\Program Files (x86)\Microsoft Visual Studio\2017\ VS_Version
\Common7\IDE\CommonExtensions\Microsoft\VSI\bin\VsdDialogs\1033
Where VS_Version is the name of your VS Version: Community, Professional etc.
Visual Studio 2013
C:\Program Files (x86)\Microsoft Visual Studio
12.0\Common7\IDE\CommonExtensions\Microsoft\VSI\bin\VsdDialogs\1033

Argument To Input Into VS12.0 Command Prompt To Open To a Specific Line Number vb.net

I'm looking to write some code to open the visual studio command prompt and move to a specific line number. Here's what I've gotten so far:
Process.Start("C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\Tools\Shortcuts\Developer Command Prompt for VS2013.lnk", "/K devenv /edit FileLocation /command ""edit.goto LineNumber""")
Command prompt opens up but I've having trouble making an argument. The command:
devenv /edit FileLocation /command "edit.goto LineNumber"
works on the command prompt, but I'm not sure how to input this command into vb.net using process.start()
First of all, don't use shortcuts to locate programs.
You should find Visual Studio's directory, instead, then execute it from there. For example, mine is located in C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE.
For example:
Process.Start("C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE\devenv.exe", "/edit ""FileLocation"" /command ""edit.goto LineNumber""")
This way you don't have to rely on the existence of the shortcut.

TeamCity FxCop Selecting MinimumRecommendedRules.ruleset has no effect

I have added a Build Step in TeamCity 8.0.6 (build 27767) to execute FxCop against a specific c# project assembly.
When running FxCop from within VS 2013 with the MinimumRecommendedRules set I get no errors or warnings (I fixed them all).
Now I want to wire this up in TeamCity. To limit the rules I am specifying a command line property as follows:
/ruleSet:=MinimumRecommendedRules.ruleset /rulesetdirectory:'FxCop\Rule Sets'
(The rulesetdirectory parameter points to a location in my source tree which contains the full contents of the standard Rule Sets folder)
However this does not have the desired behaviour, the FULL rule set is run and I get an error as follows:
FxCop warning: Keyword=CA0063 Kind=Engine Type=Microsoft.FxCop.Sdk.FxCopException * Failed to load rule set file 'MinimumRecommendedRules.ruleset' or one of its dependent rule set files.
And this is the TeamCity generated command line:
[17:32:29]Starting: "C:\Program Files (x86)\Microsoft Visual Studio 10.0\Team Tools\Static Analysis Tools\FxCop\FxCopCmd.exe" /forceoutput /ignoregeneratedcode /ruleSet:=MinimumRecommendedRules.ruleset "/rulesetdirectory:'FxCop\Rule Sets'" /f:dal\bin\release\MyDAL.dll /out:C:\TeamCity\buildAgent\temp\buildTmp\fxcop-output-1891867450083417003\fxcop-result.xml
Can anyone spot what is wrong?
I figured it out so hopefully this is helpful to someone else.
the /ruleSet: parameter needed to have the full (relative or absolute) path to the ruleset file as follows:
/ruleSet:"=%teamcity.build.workingDir%\FxCop\RuleSets\MinimumRecommendedRules.ruleset"
(Note: the double quotes are to handle the possibility that the teamcity.build.workingDir might contain spaces)
Secondly, the second command line parameter /rulesetdirectory: is no longer necessary. I suspect this second parameter does not actually work.
Please also note, my working command line parameter here points at my MinimumRecommendedRules.ruleset file in my source code. It could just as easily have been copied into the standard Rule Sets folder under "c:\Program Files (x86)\Microsoft Visual Studio 12.0\Team Tools\Static Analysis Tools\Rule Sets".
And finally, as my projects are all VS 2013 and TeamCity only recognises up as far as v10 I also set "Specifiy installation root" to "c:\Program Files (x86)\Microsoft Visual Studio 12.0\Team Tools\Static Analysis Tools\FxCop" explicitly to ensure that the latest version of FxCop was being used and would not choke on .Net 4.5 code. (Note: I have VS 2013 installed on the build server because of C++ project build requirements, I'm not happy about this but it turned out to be convenient for me in dealing with the FxCop set up. There are other ways to put the FxCop stuff on your build server without installing VS 2013)