Use .wid files with Visual Studio 2017 - vb.net

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

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

Where to put Rule Sets for MSBuild 15 (Build Tools for Visual Studio 2017)

When enabling Static Code Analysis on my builds, I get the following error thrown by MSBuild:
C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin\Microsoft.CSharp.CurrentVersion.targets(134,9): warning MSB3884: Could not find rule set file "AllRules.ruleset". [C:\Program Files\VSTS Agent_work\PATH_TO_MY.csproj]
To get Static Code Analysis working on build agents (only MSBuild, no Visual Studio), for older versions of the build tools one would:
Copy C:\Program Files (x86)\Microsoft Visual Studio 14.0\Team Tools\Static Analysis Tools\Rule Sets\ to the build server
Add a registry entry pointing to that folder
(see also this bug report)
However, these instructions doesn't work with "Build Tools for Visual Studio 2017". I'd like to know how I resolve this, without needing to copy the rulesets into my own repository or changing anything in my csproj?
Update:
I've tried setting the following registry key, to no avail:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\15.0\Setup\EDev]
"StanDir"="C:\\Program Files (x86)\\Microsoft Visual Studio\\2017\\BuildTools\\Team Tools\\Static Analysis Tools"
Digging through the registry, I've found that the following registry keys. On my machine I've installed both VS2017 Build Tools and Test Agent, and it seems like this points to the latter, which I have installed after installed Build Tools:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\VisualStudio\SxS\VS7]
"15.0"="C:\\Program Files (x86)\\Microsoft Visual Studio\\2017\\TestAgent\\"
"14.0"="C:\\Program Files (x86)\\Microsoft Visual Studio 14.0\\"
Update 2:
Both answers mention the file Microsoft.CodeAnalysis.Targets. However this file is not present on my build server. I've tried copying this folder over from my VS2017 installation:
from: C:\Program Files (x86)\Microsoft Visual Studio\2017\Community\MSBuild\Microsoft\VisualStudio\v15.0\CodeAnalysis
to: C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\Microsoft\VisualStudio\v15.0\CodeAnalysis
However besides the rulesets not being found, it now also throws errors about being unable to find Microsoft.WebApplication.targets:
XXX.csproj(296,11): error MSB4226: The imported project "C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuil
d\Microsoft\VisualStudio\v15.0\WebApplications\Microsoft.WebApplication.targets" was not found. Also, tried to find "WebApplications\Microsoft.WebApplication.targets" in the fallback search path(s) for $(VSToo
lsPath) - "C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v15.0" . These search paths are defined in "C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MSBuild\15.0\Bin\MSBuild.exe.Config".
Confirm that the path in the declaration is correct, and that the file exists on disk in one of the search paths.
Update:
Based on my test, you don't need to change anything manually, just need to install the default components of Build Tools for VS2017, then the necessary files will be added automatically.
Old:
Regarding default folder of code analysis files, you can check Microsoft.CodeAnalysis.targets file:
<PropertyGroup>
<CodeAnalysisStaticAnalysisDirectory Condition="'$(CodeAnalysisStaticAnalysisDirectory)'=='' and Exists('$(VsInstallRoot)\Team Tools\Static Analysis Tools\')">$(VsInstallRoot)\Team Tools\Static Analysis Tools\</CodeAnalysisStaticAnalysisDirectory>
<CodeAnalysisStaticAnalysisDirectory Condition="'$(CodeAnalysisStaticAnalysisDirectory)'==''">$(Registry:HKEY_LOCAL_MACHINE\Software\Microsoft\VisualStudio\15.0\Setup\EDev#StanDir)</CodeAnalysisStaticAnalysisDirectory>
<!-- If we didn't find the first registry path, assume we're in a 64bit process. -->
<!-- read registry from Wow6432Node -->
<CodeAnalysisStaticAnalysisDirectory Condition="'$(CodeAnalysisStaticAnalysisDirectory)'==''">$(Registry:HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\VisualStudio\15.0\Setup\EDev#StanDir)</CodeAnalysisStaticAnalysisDirectory>
<!-- if we didn't find the registry path yet, then try Win8 Express location -->
<CodeAnalysisStaticAnalysisDirectory Condition="'$(CodeAnalysisStaticAnalysisDirectory)'==''">$(Registry:HKEY_LOCAL_MACHINE\Software\Microsoft\VSWinExpress\15.0\Setup\EDev#StanDir)</CodeAnalysisStaticAnalysisDirectory>
<!-- If we didn't find the registry path yet, then try Win8 Express 64-bit location -->
<CodeAnalysisStaticAnalysisDirectory Condition="'$(CodeAnalysisStaticAnalysisDirectory)'==''">$(Registry:HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\VSWinExpress\15.0\Setup\EDev#StanDir)</CodeAnalysisStaticAnalysisDirectory>
<!-- If we didn't find the registry path yet, try WP Express locations -->
<CodeAnalysisStaticAnalysisDirectory Condition="'$(CodeAnalysisStaticAnalysisDirectory)'==''">$(Registry:HKEY_LOCAL_MACHINE\Software\Microsoft\VPDExpress\15.0\Setup\EDev#StanDir)</CodeAnalysisStaticAnalysisDirectory>
<!-- If we didn't find the registry path yet, try WP Express 64-bit locations -->
<CodeAnalysisStaticAnalysisDirectory Condition="'$(CodeAnalysisStaticAnalysisDirectory)'==''">$(Registry:HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\VPDExpress\15.0\Setup\EDev#StanDir)</CodeAnalysisStaticAnalysisDirectory>
<!-- If we didn't find the registry path yet, try WD Express locations -->
<CodeAnalysisStaticAnalysisDirectory Condition="'$(CodeAnalysisStaticAnalysisDirectory)'==''">$(Registry:HKEY_LOCAL_MACHINE\Software\Microsoft\WDExpress\15.0\Setup\EDev#StanDir)</CodeAnalysisStaticAnalysisDirectory>
<!-- If we didn't find the registry path yet, try WD Express 64-bit locations -->
<CodeAnalysisStaticAnalysisDirectory Condition="'$(CodeAnalysisStaticAnalysisDirectory)'==''">$(Registry:HKEY_LOCAL_MACHINE\Software\Wow6432Node\Microsoft\WDExpress\15.0\Setup\EDev#StanDir)</CodeAnalysisStaticAnalysisDirectory>
<!-- Default rule set search paths -->
<CodeAnalysisRuleSetDirectories Condition=
"'$(CodeAnalysisIgnoreBuiltInRuleSets)'!='true' and
'$(CodeAnalysisStaticAnalysisDirectory)'!=''">$(CodeAnalysisRuleSetDirectories);$(CodeAnalysisStaticAnalysisDirectory)\Rule Sets</CodeAnalysisRuleSetDirectories>
<!--
In scenario where we run CA from command-line , we don't get "CodeAnalysisVSSku" variable passed by the IDE, so in case of Express-only installation
we attempt to load rule sets that are only present on Pro and above - and fail. Let's assume we're in "Express" mode if the Pro+ rule set doesn't exist.
-->
<CodeAnalysisVSSku Condition="'$(CodeAnalysisVSSku)'=='' and !Exists('$(CodeAnalysisStaticAnalysisDirectory)\Rule Sets\NativeRecommendedRules.ruleset')">Express</CodeAnalysisVSSku>
</PropertyGroup>
Based on the code, you just need to put the code analysis rule files in $(VsInstallRoot)\Team Tools\Static Analysis Tools folder and the value of $(VsInstallRoot) is C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools if you just install Build Tools for Visual Studio 2017 on the build server.
To conclude, you just need to put rule files in C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\Team Tools\Static Analysis Tools folder.
Officially you'd need to install Visual Studio onto the build server, as the Code Analysis these rules come from are part of Visual Studio, not of MsBuild.
You can still copy the Static Analysis directory to your build server and supply the following parameter to MsBuild in the Additional Arguments option:
/p:CodeAnalysisStaticAnalysisDirectory=c:\analysisdirectory
Or copy just the rule files and specify this MsBuild argument, that's probably easiest when you put the rules files in source control:
/p:CodeAnalysisRuleDirectories=c:\analysisdirectory\rules
Optionally you could edit the project file and set the property in a property group.

Can Orchard 1.8.x be installed on a build server that does not have Visual Studio Installed?

I also asked this question on the Orchard forum but no joy there yet. So here it is again...
https://orchard.codeplex.com/discussions/569444 Please read for a few more details.
IF the .NET 4/4.5 SDK came with a developer command prompt (like previous SDKs) then I would not be asking this question.
But since Orchard is build with .NET 4.5 I am getting build errors using the old SDK. It seems that my only option is to install Visual Studio Express on the build server.
I am doing that as we speak so at this point the question is purely academic but I am still curious.
EDIT
STILL NO JOY. Even after installing VS 2013 Express Web the vcvarsall.bat that usually configure the build environment is still not present. So this is no longer a curiosity question. The Express edition also cannot create my build environment. Help.
Seth
Here is my answer...copied and pasted from the forum.
This is a late answer. Bottom line is that I did eventually get our build server to build orchard projects. I am not sure if this is a complete answer or not as I should have answered as soon as I had it done. But I pretty sure this will work.
One other thing to note...It is quite possible that not all of these steps are required. I tried a lot of different things and it might be in the end some of the steps were not needed. It might also reflect a problem on our build server...especially the fact that I had to manually add registry entries.
But here it is without details.
Install the .NET Framework SDK for Windows 7.1.
http://www.microsoft.com/en-us/download/details.aspx?id=8279
Install the .NET 4.5 Full
http://www.microsoft.com/en-us/download/details.aspx?id=30653
Install Visual Studio 2013 Express for Web
http://www.visualstudio.com/en-us/products/visual-studio-express-vs.aspx
Install the Visual Studio 2013 Build Tools
http://www.visualstudio.com/en-us/products/visual-studio-express-vs.aspx
Finally, even after that...it didn't work until I added the following registry keys. I would attach the .reg file but I don't see how.
Save the lines between the lines into a fixBuild.reg file. Then double click...
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\VisualStudio\SxS\VC7]
"FrameworkDir32"="C:\Windows\Microsoft.NET\Framework\"
"FrameworkDir64"="C:\Windows\Microsoft.NET\Framework64"
"11.0"="C:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\"
"FrameworkVer32"="v4.0.30319"
"FrameworkVer64"="v4.0.30319"
"12.0"="C:\Program Files (x86)\Microsoft Visual Studio 12.0\VC\"
Finally, to actually do the build, I created a batch file that does the build.
Save the lines between the lines into a doBuild.cmd file. Be sure to place this in the root of the source download...then double click to build...
call "C:\Program Files (x86)\Microsoft Visual Studio 12.0\Common7\Tools\VsDevCmd.bat"
msbuild /t:FastBuild Orchard.proj
The first line gets your environment ready. The second build the project using the FastBuild target in the Orchard.proj file. You can read that file if you want to try other build targets.
******* EDIT
There is one thing I forgot to mention. And that is that one thing you have to do to get this to work is that you have to edit some CSPROJ files because the command line build fails with errors like these...
\Orchard\src\Orchard.Web\Modules\CKEditor\CKEditor.csproj(337,6): error : "None" element name for include "Placement.info" should be "Content".
\Orchard\src\Orchard.Web\Modules\Orchard.Tokens\Tests\Orchard.Tokens.Tests.csproj(82,6): error : "None" element name for include "app.config" sh
\Orchard\src\Orchard.Web\Modules\TinyMceDeluxe\TinyMceDeluxe.csproj(377,6): error : "None" element name for include "app.config" should be "Cont
\Orchard\src\Orchard.Web\Modules\Upgrade\Upgrade.csproj(156,6): error : "None" element name for include "app.config" should be "Content". [C:\Us
\Orchard\src\Orchard.Web\Themes\Themes.csproj(280,6): error : "None" element name for include "Upward\Views\Content-Story.Detail.cshtml" should
The fix is to do exactly what the error indicates. Open the csproj files and search/replace "
Also, some of the projects reference app.config files that do not exist in source. You also have to remove those references. I usually just delete the content node entirely or the group entirely.
Seth

TransformXml could not be loaded

I have a old solution which worked fine with VS 2012 and now I migrate it to VS 2013.
When I try to build a configuration which involve web.config replacement i got this error:
Error 1 The "TransformXml" task could not be loaded from the assembly C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\Microsoft.Web.Publishing.Tasks.dll. Could not load file or assembly 'file:///C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\Web\Microsoft.Web.Publishing.Tasks.dll' or one of its dependencies. The system cannot find the file specified. Confirm that the declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask.
What it mean is that there no build tools in my v11.0 which is right. Because I use Visual Studio 2013. (the build tool are in a folder called v12.0) One option is to just copy my build tool to the right place but im searching for a real solution.
I found in my .csproj file these config:
<PropertyGroup>
<VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">10.0</VisualStudioVersion>
<VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
</PropertyGroup>
But im not really understand why it then v11.0 could be. I have tried multiple things to change these like set VisualStudioVersion explicit but it changed nothing.
So my question: where the heck come these path from and where can I configure it?
Since vs2012 MS tries to keep sln file untouched if there is no reason to upgrade it (to allow opening sln in the old VS).
If you’ve upgrade from vs2012 to vs2013 there can be chance you are opening solution in vs2012 (it happen to me in many updated solutions).
Try to check beginning of the sln file
Microsoft Visual Studio Solution File, Format Version 12.00
# Visual Studio 2013
or:
Microsoft Visual Studio Solution File, Format Version 12.00
# Visual Studio 2012
If you wish to change it by VS, open sln in vs2013 and then select solution root node in solution explorer and the File > Save .sln (Ctrl+S)

Web.config is being renamed by msbuild

I am using VS 2013 to build a webservice. When it is built, the Web.config file is being renamed "{projectname}.dll.config".
There is a step, _CopyAppConfigFile where it gets renamed, showing in the Output window. I can work around this, by setting the web.config to be copied always, this results in two files, web.config and x.dll.config, which I can live with, but I'd like to avoid it completely if anyone knows how.
EDIT: Looks like this is a result of a MSBuild file, located at:
C:\Program Files\MSBuild\12.0\bin\Microsoft.Common.CurrentVersion.targets
I can recreate this in a default install of Visual Studio 2013 in a C# ASP.NET MVC project. I noticed it because I am starting to transition to Visual Studio 2013, but our build server is still on Visual Studio 2012; our setup project was failing after one of my commits because the superfluous config file that I had harvested on my machine was not being generated on the build server.
This appears to be a discrepancy between the way things worked in the previous version of MSBuild 4.0 / Visual Studio 2012 and the new version MSBuild 12.0 / Visual Studio 2013.
In Visual Studio 2013, the $(ProjectConfigFileName) property is initialized to Web.config [1], which is copied to $(AppConfig) [2], which causes _CopyAppConfigFile to run [3], resulting in an unnecessary config file being named and copied over to the bin directory.
In Visual Studio 2012, the process is similar, except that its version of Microsoft.WebApplication.targets is missing this part that's in the 2013 version:
<!-- Instruct ResolveAssemblyReferences in MS.Common.targets to generate suggested binding redirects. -->
<PropertyGroup>
<AutoUnifyAssemblyReferences>false</AutoUnifyAssemblyReferences>
<AppConfig Condition="'$(AppConfig)' == '' And Exists('$(ProjectConfigFileName)')">$(ProjectConfigFileName)</AppConfig>
</PropertyGroup>
The key is that AppConfig line. Since that AppConfig reference is missing in the 2012 version, then _CopyAppConfigFile doesn't run under Visual Studio 2012, resulting in the intended behavior (i.e., the file is not copied).
In Visual Studio 2013, it looks like they added this line so that the build process could offer to fix up binding redirects for you by double-clicking on them in the Errors list in Visual Studio. When Microsoft added this, it seems no one noticed that it resulted in an extra config file being generated and copied to the output folder. So it seems to me as if it is a bug (but a mostly harmless one, since the config file is superfluous) in the new build process in Visual Studio 2013. Since it was conflicting with the Visual Studio 2012 build process on my build server, I added an extra post-build step to blow away the extraneous file:
<Target Name="AfterBuild">
<Delete ContinueOnError="true" Files="$(TargetPath).config" />
</Target>
And then you can feel better knowing that it's not a problem with your particular project or system setup, it's just the way Visual Studio 2013 does things now.
File locations referenced above:
[1] C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\Web\Microsoft.Web.Publishing.targets
[2] C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v12.0\WebApplications\Microsoft.WebApplication.targets
[3] C:\Program Files (x86)\MSBuild\12.0\Bin\Microsoft.Common.CurrentVersion.targets
I think you have the wrong project type. Did you create it as a web project? Is this in your csproj file?
{349c5851-65df-11da-9384-00065b846f21};{fae04ec0-301f-11d3-bf4b-00c04f79efbc}
From
http://www.mztools.com/articles/2008/mz2008017.aspx
349c5851-65df-11da-9384-00065b846f21 = Web Application
fae04ec0-301f-11d3-bf4b-00c04f79efbc = C# Project
Hth,
Ojf