Good time,
I use Visual Studio Build step in the TFS build, with MSBuild Arguments
/target:MyProject:publish /property:ApplicationVersion=VersionNumber
After the deploy of new version application already installed doesn't want to update. I checked manifest file, and revealed that VersionNumber applied to the version of entryPoint element, instead of version of assemblyIdentity element.
Is that fixable in the build step, or I should change manifest by my own script?
The version of assemblyIdentity is according to the target application, so you need to change AssemblyVersion in AssemblyInfo.cs file of target application. (can’t do it through MSBuild)
There are many extensions that contain related step/task to do it, such as: Assembly Info, Update AssemblyInfo. (Update the version before build)
Related
I am developing a project in VS2019. When I compile it, I receive the following warning:
warning : Your project specifies TypeScriptToolsVersion 3.7, but a matching compiler was not found. The latest available TypeScript compiler will be used (3.8). To remove this warning, install the TypeScript 3.7 SDK or update the value of TypeScriptToolsVersion.
I was trying to find where TypeScript version is specified but I did not find it. Microsoft.TypeScript.targets does not define it, however, if it would, I think I could change the value by not modifying that file directly.
Where can I fix that?
Jaime
Go to your project Properties -> "TypeScript build" tab and in the field: "TypeScript version" either choose specific version or select "Use latest available"
Look for TypeScriptToolsVersion tags in your csproj files and update to required version.
#BogdanRB answer above only displayed "Use latest available" and "4.2" for me. I did some research and apparently "4.2" is the SDK version installed together with Visual Studio 2019 (which I couldn't remove since it's required for lots of other VS components).
I was working on a legacy project that uses TypeScript "3.1.1", the version specified in package.json installed via npm. In order to line up the editor's IntelliSense and the compilation, and avoid using unsupported TS syntax, I've opened my ASP.NET Core MVC .csproj file and removed the following line:
<TypeScriptToolsVersion>Latest</TypeScriptToolsVersion>
Now Visual Studio's IntelliSense is compatible with the one specified in the npm package. It even works inside *.vue templates, in case you're using Vue with TypeScript.
I'm creating a small nuget package for internal using (I created .NET standard project to use both .NET Framework or .NET Core). I created a Build Definition to build the library then push it to the Nuget Feeds of my company.
I have 2 questions:
How can I set it automatically increase the version of the my nuget package when Queue the build in tfs 2017 & Can I set some information like Author, Company...for my package?
After having the Package in the TFS Packages. I tried to add my nuget package to my project. The nuget referenced package were not automatically added to the project. I can see, it displayed "No dependencies" but in fact, I used 2 packages in my library are Newtonsoft & StackExchange.Redis. So when I run the debug, error shown "Could not find the StackExchange.Redis..."
That's strange
In my Libary project setting, I can see
There are two ways to package nuget packages. You can use "nuget pack" or "dotnet pack" (if you have some dotnet core in your solution). The difference is that dotnet pack will create a dependency section in your nuspec and you would see dependency upon installing where nuget pack will not by default unless you use an actual nuspec file. If you do create a nuspec file, you'll need to add the dependency section to you file in order to have them pop up at installation. Check here for info on the nuspec file.
For you version number it's also actually in the nuspec file in the metadata section there is a tag with the version you want. The TFS nuget pack task as a drop down you can use to send in a version number. For this task you can either use a nuspec file or the csproj directly.
You have the same options for dotnet pack using the dotnet core task
Update:
If you change your build number version pattern in the options tab for a 4 (or 3) digit pattern like $(Date:yyyy.MM.dd).$(Rev:r) e.g. 2020.03.05.xx (where xx will increment for each build in the same day and go down to 1 the next day) or 1.0.$(Rev:r) which will be 1.0.xx that will increment forever until you change the 1.0 value and then use the "Use Build Number" it will do it for you.
I'm using the TFS step to restore my NuGet packages.
In the "Path to solution or packages.config" field I'm setting the path to the sln file.
The problem that I'm getting is that in my solution I have 2 projects:
Project "A" referencing "commom.package" version 1.1 and
project "B" referencing "commom.package" version 1.3
After the restore step I'm only getting the 1.3 version in the package directory, and after project "A" got compiled I can see in the "bin\release" folder that It's having the 1.3 version instead of the 1.1.
How can I solve this issue? Do I need to set restore for every project in the solution - meaning every package.config file?
The nuget restore task is just using nuget.exe command to restore the packages. If you use the nuget.exe command in local, will also get the same result. Package.conifg is project level, not solution level. So if you directly restore the solution in this case, it will only get one version 1.3 which apply to both projects.
However in VS , there is an option Automatically check for missing packages during build in Visual Studio. You will get both version 1.1 and 1.3 in VS restore.
To resolve this issue you have to set restore for every package.config file. Unlike restore the whole solution, you also need to use -PackagesDirectory in NuGet Arguments of the task.
I cloned the ASP.NET Core SignalR Repo locally, and try opening the solution from within the following environment.
IDE
Microsoft Visual Studio Enterprise 2015
Version 14.0.25431.01 Update 3
Microsoft .NET Framework
Version 4.6.01055
DOT NET CLI
λ dotnet --info
.NET Command Line Tools (1.0.0-preview2-1-003177)
Product Information:
Version: 1.0.0-preview2-1-003177
Commit SHA-1 hash: a2df9c2576
Runtime Environment:
OS Name: Windows
OS Version: 6.1.7601
OS Platform: Windows
RID: win7-x64
I end up seeing a lot of these kinds of error messages:
..\Repos\SignalR\src\Microsoft.AspNetCore.SignalR\Microsoft.AspNetCore.SignalR.csproj
: error : The default XML namespace of the project must be the
MSBuild XML namespace. If the project is authored in the MSBuild 2003
format, please add
xmlns="http://schemas.microsoft.com/developer/msbuild/2003" to the
element. If the project has been authored in the old 1.0 or
1.2 format, please convert it to MSBuild 2003 format. ..\Repos\SignalR\src\Microsoft.AspNetCore.SignalR\Microsoft.AspNetCore.SignalR.csproj
I want to know how to fix this the correct way.
The projects you are trying to open are in the new .NET Core csproj format. This means you need to use Visual Studio 2017 which supports this new format.
For a little bit of history, initially .NET Core used project.json instead of *.csproj. However, after some considerable internal deliberation at Microsoft, they decided to go back to csproj but with a much cleaner and updated format. However, this new format is only supported in VS2017.
If you want to open the projects but don't want to wait until March 7th for the official VS2017 release, you could use Visual Studio Code instead.
I ran into this issue while opening the Service Fabric GettingStartedApplication in Visual Studio 2015. The original solution was built on .NET Core in VS 2017 and I got the same error when opening in 2015.
Here are the steps I followed to resolve the issue.
Right click on (load Failed) project and edit in visual studio.
Saw the following line in the Project tag: <Project Sdk="Microsoft.NET.Sdk.Web" >
Followed the instruction shown in the error message to add xmlns="http://schemas.microsoft.com/developer/msbuild/2003" to this tag
It should now look like:
<Project Sdk="Microsoft.NET.Sdk.Web" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
Reloading the project gave me the next error (yours may be different based on what is included in your project)
Saw that None element had an update attribute as below:
<None Update="wwwroot\**\*;Views\**\*;Areas\**\Views">
<CopyToPublishDirectory>PreserveNewest</CopyToPublishDirectory>
</None>
Commented that out as below.
<!--<None Update="wwwroot\**\*;Views\**\*;Areas\**\Views">
<CopyToPublishDirectory>PreserveNewest</CopyToPublishDirectory>
</None>-->
Onto the next error: Version in Package Reference is unrecognized
Saw that Version is there in csproj xml as below (Additional PackageReference lines removed for brevity)
Stripped the Version attribute
<PackageReference Include="Microsoft.AspNetCore.Diagnostics" />
<PackageReference Include="Microsoft.AspNetCore.Mvc" />
I now get the following:
Bingo! The visual Studio One-way upgrade kicked in! Let VS do the magic!
The Project loaded but with reference lib errors.
Fixed the reference lib errors individually, by removing and replacing in NuGet to get the project working!
Hope this helps another code traveler :-D
#DavidG's answer is correct, but I would like to add that if you're building from the command line, the equivalent solution is to make sure that you're using the appropriate version of msbuild (in this particular case, it needs to be version 15).
Run msbuild -version to see which version you're using or where msbuild to check which location the environment takes the executable from and update (or point to the right location of) the tools if necessary.
Download the latest MSBuild tool from here.
If getting this error trying to build .Net Core 2.0 app on VSTS then ensure your build definition is using the Hosted VS2017 Agent queue.
I was getting the same messages while I was running just msbuild from powershell.
dotnet msbuild "./project.csproj" worked for me.
if the project is not a big ,
1- change the name of folder project
2- make a new project with the same project (before renaming)
3- add existing files from the old project to the new project (totally same , same folders , same names , ...)
4- open the the new project file (as xml ) and the old project
5- copy the new project file (xml content ) and paste it in the old project file
6- delete the old project
7- rename the old folder project to old name
I had the same problem and solved it by using dotnet instead of msbuild.
HI
I am trying to build my solution using TFS but it seems to skips the projects which have dependencies.
e.g Proj B depends on Proj A , then it builds only Proj A and not Proj B.
Also if i try to build the projects individually instead of the solution then it does not create the release folder. It says that the output path is not found.
Any help is much appreciated
thanks
Is the SLN file in question converted from an older version of Visual Studio?
I've found that sometimes, like when you upgrade from a VS2003 SLN file to a VS2008 SLN file, it fails in MSBuild (which is what TFS is doing essentially).
Try making a new SLN file in VS2008 (or whatever version you're using) with the same project and see if that fixes it...
If you right-click the solution, one option you'll have is dependencies. Make sure that the projects are correctly setup there, even though they may reference each other the dependencies on the solution itself may not be complete or accurate...and this is what MSBuild uses.
Have a look in the configuration manager and make sure that the build you are running has those projects selected to build.
It may be you are running the Debug configuration for your local build and then running Release on the TFS server and it's not configured the same.