I inherited a lot of stuff that is above my knowledge level, but I am the only one here that is close enough to that level to figure it out. I feel like I learn quickly, and I have been able to jump every hurdle so far without too much time taken, but I just can't figure this out!
Basically we use TFS 2015 and in that we have a build definition that goes through an agent on a remote computer (that I can remote into).So, one of the developers checked in code with an updated NuGet package (Newtonsoft.Json) and it broke the build. The files and everything build locally just fine, but the build bot is broken.
I have a screenshot on imgur for a little context in my build definition and the webhook we use to send the notification in slack links to a an error page that tells me "error: Build Not Found" so I am all kinds of confused and I can't find anything online that can help me.
EDIT:
In my build logs I got this error
Error CS0246: The type or namespace name 'DataSourceRequest' could not be found (are you missing a using directive or an assembly reference?)
All of my other branch builds work and the only difference is that I updated the nuget package. Is there any way for me to upgrade the nuget package in the build agent?
Screenshot of Build Definition:
Build Definition Not Building After Nuget package Update In Visual Studio
AFAIK, the reason of this issue may be that you upgraded the package Newtonsoft.Json to version 9.01 or higher.
Starting from Newtonsoft.Json 9.0.1, this package supports the targets framework .NETStandard:
https://www.nuget.org/packages/Newtonsoft.Json/9.0.1:
Which is supported by NuGet 2.12 for Visual Studio 2013:
NuGet 2.12 Release Notes
Full NetStandard and NetCoreApp support for VS2013.
So, to resolve this issue, you should make sure the nuget.exe version is higher than 2.12 and the Visual Studio version is high than 2013.
Besides, as we know, Visual Studio are backwards compatible. Meaning we could use the lower version Visual Studio to develop the project and we could build it with a higher version of Visual Studio on the agent. But if the other way around, develop it with higher version, build it with lower version on the agent, we may encounter some issues due to compatibility. So, If we keep that the Visual Studio version on the agent is higher than the version you are developing, it would be better.
Hope this helps.
Related
I'm using Visual Studio Professional 2017, version 15.6.6. A co-worker gave me a solution which he says I should be able to open and rebuild without any problems. There seems to be something wrong with either the NuGet packages and/or Framework. Co-worker will only say it must be something wrong with my computer, so I'm hoping someone here can help.
I tried right clicking on the solution and picking "Restore NuGet Packages". The references still have the yellow triangle by them. I tried to rebuild anyway and got the message "The reference assembilies for framework ".NETFramework, Version=v6.0" were not found. I looked at the project properties and saw the target framework was blank. I tried choosing .NET Framework 4.6, but that gave me multiple errors of the type "Package [name of NuGet package] is not compatible with net46(.NETFramework, Version=v4.6)." The co-worker had mentioned trying .NET Core before, so I tried downloading .NET Core 3.1 from this site: https://dotnet.microsoft.com/en-us/download/visual-studio-sdks?cid=getdotnetsdk. I installed it (including restarting my computer), but don't see .NET Core in the Target framework. Can anyone help guide me getting this solution running?
Here's an image showing the missing references (yellow triangle) on the right and the reference error message when I tried to rebuild.
Here's an image after I set the framework to 4.6 and showing the target framework choices I have available:
We can see that:
.NET 6 is supported by Visual Studio 2022 and Visual Studio 2022 for Mac (and later versions).
You can update to VS2022 and try again.
I'd like our developers to use one version of Visual Studio for all of our projects (where possible) - to that end, I've asked them to use VS2019 for some projects that were originally created in VS2010 and then migrated to VS2013.
A runtime behavior change occurred when running one of these old webforms applications in VS2019. I'm not sure why it's different since the dlls being used are the same and the compiled IL is the same for the method in question, but at the moment I don't really care about "fixing" it since it would require making code changes and regression testing the entire application; a path I'd like to avoid for the moment.
What I'd like to do is make sure VS2019 builds with the indicated tools so that we retain the old behavior. The project file is referencing tools version 12 (VS2013 is not installed), but when Visual Studio builds I see the following in the MSBuild output:
Project file contains ToolsVersion="12.0". This toolset may be unknown or missing, in which case you may be able to resolve this by installing the appropriate version of MSBuild, or the build may have been forced to a particular ToolsVersion for policy reasons. Treating the project as if it had ToolsVersion="Current". For more information, please see http://go.microsoft.com/fwlink/?LinkId=293424.
I installed MSBuild Tools 2013, but that didn't correct the issue before or after a restart. I also tried with tools version 15 and got the same error (VS2017 is installed).
MSBuild from the VS2019 dev command prompt worked, but I had to copy the 14.0 webapplication targets to a new folder named "16.0". I'm not sure why there is a 14.0 folder but no 12.0 or 15.0 folder without doing more searching online.
Is this a fool's errand, or am I missing something simple?
MSBuild from the VS2019 dev command prompt worked, but I had to copy
the 14.0 webapplication targets to a new folder named "16.0". I'm not
sure why there is a 14.0 folder but no 12.0 or 15.0 folder without
doing more searching online.
Update 1
This is just a prompt warning to ensure that you'd better use the related MSBuild version to build the project. It is designed as a reminder message.
But in fact, MSBuild does add backward compatibility feature.
The message is just a warning rather than an error and will not break the build process. And if it breaks the build process, it can prove that backward compatibility is not supported.
You can test it: use VS2019 to build a VS2017 or VS2015 projects and I am sure that it can built them successfully.
==============================================
Each version of VS creates a project that is built for the corresponding MSBuild version.
For example, in the project created in VS2010, its ToolsVersion="4.0", so when you use MSBuild from VS2010(msbuild v4.0), it will built without that warning.
VS2013-->ToolsVersion=12.0 , VS2015-->ToolsVersion=14.0 , VS2017-->ToolsVersion=15.0, VS2019--> ToolsVersion=Current
So when you build the project, you should try the related msbuild version to build them.
Although MSBuild supports backwards compatibility, the problem is always in the form of a warning, which has been troubling us during the project migration.
Solution
To solve it, you should use the related MSBuild to build the project with the corresponding ToolsVersion.
If you want to build them in VS2017, you should change ToolsVersion to 15.0 in every project's xxx.xxproj file.
If you want to build them in VS2019, you should change ToolsVersion to Current in every project's xxx.xxproj file.
More info, you can refer to my answer in this similar issue.
I am using VSTS for a project that is using TypeScript. We have a CI Build configured and suddenly that one stopped working today. Yesterday all was fine, today they are all failing.
Looking into the build logs I discovered that it's not finding the TypeScript compiler that we specified:
Warning : Your project specifies TypeScriptToolsVersion 2.1, but a matching compiler was not found. The latest available TypeScript compiler will be used (2.4). To remove this warning, install the TypeScript 2.1 SDK or update the value of TypeScriptToolsVersion.
So all of a sudden it starts compiling with TypeScript 2.4 and we have some code that's not compatible with that version (Promises).
I have defined the TypeScript Tools Version in our .csproj as
<TypeScriptToolsVersion>2.1</TypeScriptToolsVersion>
and that seems to be working as I read in the build logs that it tried using that one first.
Any idea what caused VSTS suddenly to "forget" about TypeScript 2.1 and how I can fix this? I could not find any update notification or anything.
Right click on Project and click properties
Click on TypeScriptBuild and Select Use Latest Available
That means the TypeScript SDK has been updated on build server. If you are using private build agent, you can check it on your build server. If you are using Hosted agent, it will be updated irregularly (official article isn’t updated)
Regarding this issue, you can refer to these threads:
For VS 2015 project (Microsoft.TypeScript.MSBuild package): Visual Studio Team Services build Typescript error
For VS 2017 project (Microsoft.TypeScript.MSBuild package): Angular4.1 with .NET Core1.1 build fails in VSTS Hosted VS2017 agent
I have a project built in VS 2013, for some reason I cannot build in release mode only debug mode. If I build in release mode I get a bunch of errors that doesn't really seem relavant. Anyone got any suggestion on where to begin looking for errors?
From your error I can guess that you're using an external library, either through NuGet or locally.
You have to set up the environment to use this library in both release and debug mode. That means installing it on either one through NuGet or setting up the correct include/library paths in the project settings.
In my case it was an unrelated Nuget package that had a higher .Net Framework version than my project.
I had a similar problem, with the same error of Invalid pointer, and it turned out that I had uninstalled Telerik from machine.
1. Make sure that you have Telerik installed , on my machine it is under "C:\Program Files (x86)\Telerik\UI for ASP.NET AJAX Q3 2015\"
The file "Telerik.Web.UI.dll" is available in the Bin[nn]-folders, select the one you want (perhaps the latest version).
2. In visual studio; if your reference to "Telerik.Web.UI" has a yellow warning triangle it indicates that Visual Studio cannot locate the dll file.
Add new reference by browsing your Telerik Bin[nn] folder and selecting the file "Telerik.Web.UI.dll" (and repeat this for all projects using the Telerik components in your solution)
When I try to register a visual studio package using regpkg in Visual Studio 11 RC, I get the following error:
regpkg.exe /root:Software\Microsoft\VisualStudio\11.0 /codebase myvspackage.dll
Could not load file or assembly 'Microsoft.VisualStudio.Shell, Version=2.0.0.0,
Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or one of its dependencies. The
system cannot find the file specified.
This worked fine with previous versions of Visual Studio. I'm working in a clean virtual machine that only has Visual Studio 2012 RC.
I've been surfing the web looking for a solution with no success.
If I just copy the Microsoft.VisualStudio.Shell.dll in my app location it works fine, but this dll is not redistributable, so... what's the right way of registering a package in Visual Studio 11?
Thanks in advance for your help,
Luis
I'll assume you also posted this to the MSDN forums since a question with identical text was posted there which I answered yesterday.
http://social.msdn.microsoft.com/Forums/en-US/vsx/thread/96556cd4-44dd-4e01-8198-b83a66c6df26
In short it sounds like you have an explicit reference to v2 of Microsoft.VisualStudio.Shell.dll, James is incorrect in saying you aren't supposed to use this, this is simply MPF from 2005. Referencing it is perfectly fine. If you have an explicit version in the reference in the project file try dropping it, if not try adding the binding redirect mentioned in my MSDN forum post.
I have started a mail with the SDK team about this issue though I don't know if they will be taking any changes this close to release. Also, as an FYI, since Shell.dll is from 2005, it is nearing the end of its supported life, we generally support three versions of previous VS releases.
On release of 2012 the support will be 2008,2010, 2012. I suspect in the next release (after 2012) we may stop including Shell.dll (the 2005 version) entirely in the shipped product. Unless you need to run downlevel on say 2005 I would update the reference to one of the newer shell assemblies (like 9.0, 10.0 or 11.0)