Whenever I try to open a VB solution on Visual Studio 2013 it won't open. Instead I can open the vb file but I can't run the program. Whenever I run it, it gives me this error message.
C:\Users\George\Documents\Visual Studio 2013\Projects\RealCalc\RealCalc\RealCalc.vbproj : error : The project file could not be loaded. Root element is missing. C:\Users\George\Documents\Visual Studio 2013\Projects\RealCalc\RealCalc\RealCalc.vbproj.user
Please help
Sounds like either your vbproj or vbproj.user file is corrupted. The first few lines of these files should look like this (note the root XML node):
vbproj:
<?xml version="1.0" encoding="utf-8"?>
<Project DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="12.0">
<PropertyGroup>
...
vbproj.user:
<?xml version="1.0" encoding="utf-8"?>
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003" ToolsVersion="12.0">
<PropertyGroup>
...
I'd suggest trying to fix it by hand using a good text editor. You can also try deleting the vbproj.user file altogether and letting VS regenerate it.
Related
At the moment we are switching from VS2015 to VS2017. One of our upgrade steps is to switch from stylecop to the new Stylecop.Analyzer package. The new Stylecop is using 2 files. The stylecop.json and the Stylecop.ruleset.
The target: I want to provide the stylecop files as a custom nuget package. But I dont know how to create the needed .csproj entries.
<Project Sdk="Microsoft.NET.Sdk">
<PropertyGroup>
...
<CodeAnalysisRuleSet>packages\My.StyleCop.1.0.0-pre15\RuleSet\My.StyleCop.ruleset</CodeAnalysisRuleSet>
</PropertyGroup>
...
<ItemGroup>
<AdditionalFiles Include="packages\My.StyleCop.1.0.0-pre15\Config\stylecop.json">
<Link>stylecop.json</Link>
</AdditionalFiles>
</ItemGroup>
</Project>
In the past, there was the possibility to use a install.ps1 script to do this stuff. But with NuGet 3. (or 4.) the install scripts are obsolete and will be ignored.
I already tried to use My.StyleCop.targets:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ItemGroup>
<AdditionalFiles Include="packages\My.StyleCop.1.0.0-pre17\Config\stylecop.json">
<Link>stylecop.json</Link>
</AdditionalFiles>
</ItemGroup>
</Project>
But here I have some issues, too. Since NuGet 3. (or 4.) there is no solution wide package folder and I dont know any variable or placeholder I can use here to get a absolute or relative path to my package.
You can add .props or .targets files to the build folder in your packages and they will be imported to the projects.
On the .props file, you can use the MSBuildThisFileDirectory MSBuild variable that represents the folder where that file is located.
Thanks to Paulo.
How I did it:
This is the structure of my NuGet package.
The solution is quiet easy. You need to create to files. A .props and a .targets file named like the NuGet package and place them in the build folder of your package.
In these MSBuild files you can use the $(MSBuildThisFileDirectory) variable to get the path of your NuGet package.
MSBuildThisFileDirectory = C:\Users\UserName\.nuget\packages\sig.stylecop\1.0.0-pre23\build\
My SIG.StyleCop.props file:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<CodeAnalysisRuleSet>$(MSBuildThisFileDirectory)\..\RuleSet\SIG.combiLink.ruleset</CodeAnalysisRuleSet>
</PropertyGroup>
</Project>
My SIG.StyleCop.targets file:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<ItemGroup>
<AdditionalFiles Include="$(MSBuildThisFileDirectory)\..\Config\stylecop.json">
<Link>stylecop.json</Link>
</AdditionalFiles>
</ItemGroup>
</Project>
Cause of the structure of my package i need to navigate (..) into the Config and into the RuleSet folder.
The variable $(MSBuildThisFileDirectory) already includes the backslash at the end. It is important to omit the backslash when you reference the ruleset and the stylecop.json file:
<CodeAnalysisRuleSet>$(MSBuildThisFileDirectory)..\RuleSet\SIG.combiLink.ruleset</CodeAnalysisRuleSet>
<AdditionalFiles Include="$(MSBuildThisFileDirectory)..\Config\stylecop.json">
With the double backslash I experienced two strange problems in Visual Studio 2017:
Unit tests rebuild the code each time I start them, even without any code change
The IDE shows many StyleCop errors in the Error List window and shows red marks in the scroll bar even for rules that are explicitly disabled in the rule set.
I am using following script within my build file. I have installed MSBuildExtensionPack on the build server.
<?xml version="1.0" encoding="utf-8"?>
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003"
ToolsVersion="4.0"
DefaultTargets="StopIT">
<Import Project=".\thirdparty\tools\MsBuildExtensions"/>
<Target Name="StopIT">
<MSBuild.ExtensionPack.Computer.WindowsService TaskAction="Stop" ServiceName="AppServices" MachineName="MyMachineName"/>
</Target>
</Project>
After running the script, I am getting following error:
The imported project "C:\Program Files (x86)\MSBuild\ExtensionPack\4.0\MSBuild.ExtensionPack.tasks" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk.
If i look into the machine, I can find this file under: "C:\Program Files\MSBuild\ExtensionPack\4.0\MSBuild.ExtensionPack.tasks" location.
How can I inform the build script to look into correct path.
To answer my own question, I installed the 32 bit version which by default get installed at C:\Program Files (x86)\MSBuild\ExtensionPack\4.0 location. I am not sure if there is an explicit way to specify another path.
Thank you
I am trying to use MSBuildExtensionPack and read that I have to import the project by using:
$(MSBuildProjectDirectory)..\MSBuild.ExtensionPack.tasks
$(MSBuildProjectDirectory)....\Common\MSBuild.ExtensionPack.tasks
It should not be necessary for you to include the above type of import in your usage of the tasks. If you have used the default installation path, simply use the following imports:
3.5 ---
4.0 ---
I have not installed the extension pack on the build server, rather I have copied the DLL into a specifc location and trying to access it by following code:
After trigerring the build using TeamCity, I get following error:
error MSB4019: The imported project "C:\Apps\Teamcity\buildAgent 1\work\vb82348r312dsd33\thirdparty\tools\MsBuildExtensions" was not found. Confirm that the path in the declaration is correct, and that the file exists on disk.
If I look into the build machine, I can find the folder and all the files in it. Not sure why I am getting this error.
<?xml version="1.0" encoding="utf-8"?>
<Project xmlns="http://schemas.microsoft.com/developer/msbuild/2003"
ToolsVersion="4.0"
DefaultTargets="StopIT">
<Import Project=".\thirdparty\tools\MsBuildExtensions"/>
<Target Name="StopIT">
<MSBuild.ExtensionPack.Computer.WindowsService TaskAction="Stop" ServiceName="AppServices" MachineName="MyMachineName"/>
</Target>
</Project>
Please provide your suggestion
You need to change your import from
<Import Project=".\thirdparty\tools\MsBuildExtensions"/>
to
<Import Project=".\thirdparty\tools\MsBuildExtensions\MSBuild.ExtensionPack.tasks"/>
It is not enough to name the folder, you have to name every file (.proj, .target, .tasks) that should be imported, in your case the MSBuild.ExtensionPack.tasks
The tasks file contains some kind of mapping between task names and the assembly where to find them.
I'm attempting to automate the building of our installers through MSBuild. The problem that I have come up against is getting the Version information of the C# project which is calling the custom MSBuild script, which would then pass the version number into Wix during the build process.
What I would like to do is to set the version into some properties like this:
<ProductVersion>$(MajorVersion).$(MinorVersion).$(PatchVersion).$(BuildVersion)</ProductVersion>
<InstallerName>"$(ProductName)-$(ProductVersion).msi"</InstallerName>
The version is updated as part of our continuous integration build and incorporating the version number into each installer that is built on our continuous integration server helps us in producing an application that is Continuously Deployable.
Any help would be greatly appreciated.
The way I have solved this problem is by creating a 'version.xml' file in my code repository. This file contains the following data
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="3.5"
DefaultTargets="Build"
xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<PropertyGroup>
<VersionMajor>0</VersionMajor>
<VersionMinor>1</VersionMinor>
<VersionBuild>1</VersionBuild>
<VersionRevision>0</VersionRevision>
</PropertyGroup>
</Project>
In my case this file is checked in but it should not be too hard to generate this file with information from the build server or whatever is desired.
During the build a custom MsBuild taks (similar to the TemplateFile task) creates an assembly info file and a Wix include file from their respective template files. The 'version.xml' file is accessed by including it in the MsBuild script. For example like this:
<?xml version="1.0" encoding="utf-8"?>
<Project
ToolsVersion="4.0"
DefaultTargets="Build"
xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
<!-- Include the version info file so that we can pull the version info from it -->
<Import
Project="$(DirWorkspace)\version.xml"
Condition="Exists('$(DirWorkspace)\version.xml')" />
<!-- Generate a file with the version information -->
<Target Name="GenerateAssemblyInfoVersionNumber">
<ItemGroup>
<VersionTokens Include="Major">
<ReplacementValue>$(VersionMajor)</ReplacementValue>
</VersionTokens>
<VersionTokens Include="Minor">
<ReplacementValue>$(VersionMinor)</ReplacementValue>
</VersionTokens>
<VersionTokens Include="Build">
<ReplacementValue>$(VersionBuild)</ReplacementValue>
</VersionTokens>
<VersionTokens Include="Revision">
<ReplacementValue>$(VersionRevision)</ReplacementValue>
</VersionTokens>
</ItemGroup>
<TemplateFile
Template="$(FileTemplateAssemblyVersion)"
OutputFileName="$(FileGeneratedAssemblyVersion)"
Tokens="#(VersionTokens)" />
</Target>
</Project>
The AssemblyInfo.VersionNumber.cs file which is included in the C# projects is generated from a template file that looks like:
//-----------------------------------------------------------------------
// <auto-generated>
// This code was generated by a tool.
//
// Changes to this file may cause incorrect behavior and will be lost
// if the code is regenerated.
// </auto-generated>
//-----------------------------------------------------------------------
using System.Reflection;
[assembly: AssemblyVersion("${Major}.${Minor}.${Build}.${Revision}")]
[assembly: AssemblyFileVersion("${Major}.${Minor}.${Build}.${Revision}")]
// The AssemblyInformationalVersion stores the version that will be displayed in
// Windows explorer.
[assembly: AssemblyInformationalVersion("${Major}.${Minor}.${Build}.${Revision}")]
During the replacement process the ${TEXT_HERE} sections are replaced with their respective values.
The Wix include template file looks like this:
<?xml version="1.0" encoding="utf-8"?>
<Include xmlns="http://schemas.microsoft.com/wix/2006/wi">
<!--
This is a generated file.
Do NOT make changes to this file.
They will be undone next time the file is generated.
-->
<!-- The current version -->
<?define CurrentVersion = "${Major}.${Minor}.${Build}"?>
<!-- The install version string -->
<?define ProductVersionFolder = "${Major}.${Minor}"?>
</Include>
After including this file it is possible to refer to the CurrentVersion and the ProductVersionFolder variables in the Wix installer where ever it is needed.
By using this method the version information is stored in a single location and can be accessed by all parts of the build.
I am trying to specify some additional targets/tasks to an msbuild file by extending an existing msbuild file (a web applicartion .csproj file). The idea is to put configuration specific tasks in this "extended ms build file" and use this file in our build server (TeamCity). The way I tried to solve it at first was to add a folder "msbuildscripts" to my web project and put the extended ms build file there:
<?xml version="1.0" encoding="utf-8" ?>
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="Build">
<Import Project="../My.Web.csproj" />
...more stuff...
</Project>
and then build this file using something like:
c:\myweb\msbuild.exe msbuildscripts/extended.msbuild.file.xml
Now, this wont work because when importing the original ms build file, that csproj file will be "executed" in the "wrong" folder (msbuildscripts), and the csproj-build-file wont find any of its referenced folders/items.
Is there any way to tell msbuild.exe to use a specific working directory? I know it is possible to solve this problem using an execute task, but that doesnt seem like a good solution.
Use MSBuild task like this:
<Project ToolsVersion="4.0" xmlns="http://schemas.microsoft.com/developer/msbuild/2003" DefaultTargets="MyBuild">
<ItemGroup>
<ProjectToBuild Include="../My.Web.csproj" />
</ItemGroup>
<Target Name="MyBuild">
<MSBuild Targets="Build" Projects="#(ProjectToBuild)"></MSBuild>
</Target>
</Project>