I am trying to generate help files using Sandcastle, locally this works find but on my build server I keep receiving the same error message:
SHFB: Error BE0073: A project with a different or higher framework version was
found but that version (.NETFramework 4.5) or a suitable redirected version
was not found
I have checked and I have .NET 4.5.1 installed and 4.5, my projects build without an issue on the server. It is only Sandcastle that is causing a problem.
Does anyone know the cause of this error or how I can diagnose it further?
For some reason the directory:
C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.5
Was missing on my build server. I copied it from my local machine and everything started to work.
I was experiencing the same issue trying to configure VSTS.
SHFB: Error BE0071: Unable to locate information for the project framework version '.NET Framework 4.6.1' or a suitable redirected version on this system. See error number help topic for details.
The LastBuild.log showed that it was not finding the .NETFramework folder.
Finding tools...
The Sandcastle tools are located in 'd:\a\1\s\packages\EWSoftware.SHFB.2017.1.28.0\Tools\'
The SHFBROOT system environment variable was not found. This variable is usually created during installation and may require a reboot. It has been defined temporarily for this process as: SHFBROOT=d:\a\1\s\packages\EWSoftware.SHFB.2017.1.28.0\Tools\
Locating components in the following folder(s):
d:\a\1\s\Documentation\Project.Docs
C:\ProgramData\EWSoftware\Sandcastle Help File Builder\Components and Plug-Ins\
d:\a\1\s\packages\EWSoftware.SHFB.2017.1.28.0\Tools\
Last step completed in 00:00:00.0360
I ended up setting the Project-specific components path in the project properties to point to the SHFB .NET Framework package and this solved the problem.
For me this message occurred after I had installed the Sandcastle Help File Builder application on our build server, but the build logs were complaining that the SHFBROOT environment variable wasn't found, but I had configured an override in the Help File Builder project which the build log said it would use instead.
<PropertyGroup>
<!-- NOTE: Update the version number in the path (YYYY.M.D.R) to match the package version -->
<SHFBROOT Condition=" '$(SHFBROOT)' == '' ">$(MSBuildThisFileDirectory)\..\packages\EWSoftware.SHFB.2017.1.28.0\tools\</SHFBROOT>
</PropertyGroup>
The above setting didn't help me on the build server however and it was still failing (but not locally).
What did work for my case was a reboot of our build server.
A fairly obvious oversight on my part, as I expect this is somewhere in the help documentation that I may have initially missed.
I had this related issue with running it on the build server:
BE0071: Unable to locate information for the project framework version 'XXXX'
Cause
The build engine was unable to locate framework information for the version specified in the project's FrameworkVersion property. An attempt was made to redirect usage to a later version but none were found.
Solution
This can happen if you select a framework that is not installed on the system. For example, choosing an earlier version of the Silverlight framework. If the earlier version is not found, the build engine will attempt to redirect usage to a later version of the framework if one can be found on the system. If the specified version or a later version cannot be found, you will need to install the selected or later version of the framework specified in the project on the system.
The framework assemblies are searched for in the Reference Assemblies folder (%ProgramFiles(x86)%\Reference Assemblies\Microsoft\Framework). If you have not installed a version of Visual Studio related to the indicated framework version or the related targeting pack, the reference assemblies may not exist there. The simplest solution is to download and install the appropriate targeting pack or copy the reference assemblies from another system that does have them.
If using the Sandcastle Help File Builder NuGet package, it may mean that you need to install one or more of the help file builder Reflection Data Set packages which contain the necessary files. If multiple versions of the platform package exist, install the latest release as it will cover all prior releases as well. Be sure to set the project's Component Path project property to the packages folder if it is not under the help file build project folder. Once installed and the component path is set, you may need to close and reopen the project in order for it to detect the newly installed files.
Related
trying to start a .NET console application. Would prefer F# but get the same error in C# or VB as well.
Unable to locate the .NET SDK as specified by global.json, please check that the specified version is installed. I get that warning as soon as I create a new application, and get it as an error when I try to build.
This is using the default Hello World templates that come with Visual Studio. I would expect the prebuilt templates that ship with the app to build first time. Using VS 2019 16.8.5.
I have searched Visual Studio project and the source directory and can't find any global.json.
EDIT: Found the global.json at C:\users\username
{
"sdk": {
"version": "3.1.300",
"rollForward": "latestMinor"
}
}
Which I'm fairly sure I have the SDK installed for but will double check.
In my case my global.json was referring to an SDK I didn't have. Run the below in your terminal
dotnet --list-sdks
That will give you the list of all the SDK's available, here you can either update your global.json file to the version you have (or install the missing SDK if you need to)
I would advise removing that global.json file instead of just adding latestMajor to it, since it's in a place where it probably shouldn't be. Having one in the root of C:\users\your-name with that value is functionally equivalent to not having it in the first place.
The general purpose of a global.json file is to lock down the SDK version used for a specific codebase. For example, this can be helpful if you're using a CI system that can install a .NET SDK based on a global.json file, so you don't have multiple places to update your toolset over time.
Check rollForward is disabled or not
If disabled the make it latestMinor
"rollForward": "latestMinor"
I have a vsix project. I use commandtool and create files. I upgraded .net framework (4.6.1 to 4.7.2) and packages
I run project, everything is ok. But I get error when I click Extension's button.
I checked error in XML file. Error description is
Description: Could not load file or assembly Microsoft.VisualStudio.Threading, Version=16.8.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a; or one of its dependencies
But there is package in References
Do you have any idea?
Best Regards
When you upgraded to the newer version of Microsoft.VisualStudio.Threading, you upgraded to a version that's higher than what your Visual Studio is shipping with as a part of the platform. Although there are ways you could make your version now be the preferred version, the easiest answer is probably 'don't do that', since you're artificially limiting which versions of VS your extension could install onto.
Unless you had a specific reason to upgrade, you're probably best off leaving the version there.
When I'm trying to update or configure service reference in .NET 4.6.1 project, VS throws next error:
Could not resolve mscorlib for target framework '.NETFramework,Version=v4.6.1'. This can happen if the target framework is not installed or if the framework moniker is incorrectly formatted.
Path lenght is OK, I'd also checked another answers on SO and nothing works.
Maybe someone has something like that?
I get the same error on VS2019.
This error occurred because I never restored nuget packages and built the solution.
After a restore of nuget packages and a full rebuild of the solution the error disappeared!
It is hard to confirm, but I believe my issue had to do with exceeding a TFS limit of 259 characters in the path. In short, when getting latest from TFS, I think some files were not downloading to my local machine due to their path exceeding 259 characters.
After renaming the working directory to a shorter path, I was able to configure existing and new service references. Here's one link discussing the limitation: TFS Path Too Long Problems
I had the same issue with VS 16.10.0 Preview 1.0 for 4.8
To fit it I did first clean project, then retargeted from 4.8 to 4.7.2 and back and then it worked.
In my case going into the project folders and manually deleting contents of:
/bin
/obj of each project in the solution. And then contents of
/packages in solution folder
then reopening solution and rebuilding + restoring the nuget packages worked.
You should refresh the target framework in the Application properties of the project
In my situation; I was rebuilding a projected I had worked on using Visual Studio 2010. To resolve this error, I downloaded the .NET Framework 4.8 Developer Pack via this site https://dotnet.microsoft.com/en-us/download/visual-studio-sdks?cid=getdotnetsdk
I restarted my IDE and everything was fine.
I am new to Visual Studio, so please be patient.
I am working on a product that depends on a dll file that is provided by a third party. We will call them OtherCompany.dll. We do not distribute this.
Our product contains a dll file that is dependent on OtherCompany.dll. We will call it MyCompany.dll. When we build MyCompany.dll, we are currently building against version 1.0.0 of OtherCompany.dll. However, we recently discovered that OtherCompany.dll changed its version to 2.0.0. There were no changes to existing functionality, only additions.
Some users purchased OtherCompany.dll version 2.0.0 and now our product breaks as version 1.0.0 is not in the GAC. I understand this is a common issue, and I have been trying to discover a good solution.
I attempted to add into my .csproj file for our MyCompany.dll and building against OtherCompany.dll version 1.0.0, and install it on a machine with OtherCompany.dll version 2.0.0. It is still failing with the error
Could not load file or assembly 'OtherCompany, Version=1.0.0, Culture=neutral, PublicKeyToken=1234' or one of its dependencies. The system cannot find the file specified.
I understood that would allow MyCompany.dll to be version independent of OtherCompany.dll. What did I do wrong or misunderstand ?
I was able to get things to work by manually adding into the products .config file, but this is cumbersome and I would like something that would continue to work, in case next week OtherCompany.dll releases version 3.0.0.
I've installed a complete SharePoint Server (MOSS) 2007 on my dev box + the latest Visual Studio (SP1) + the latest full Windows SDK. According to the Windows Workflow Foundation page http://msdn.microsoft.com/en-us/netframework/dd980558.aspx, that is all I should need to do to be able program against the .NET Workflow APIs.
And yet, all of the projects I build from the standard Workflow templates refer to the assembly System.Workflow and VS complains that that assembly isn't available. I've searched around on my hard drive, and I can't find a file for that assembly anywhere obvious on my disk.
I do find some files that look like they might be that assembly, but they're buried down in wacky places below particular applications like they are runtime support for that app. They don't seem to be what I'm supposed to point VS at.
Can anyone tell me how to fix this problem? Do I need to install something else that I have yet to come across? Are these assemblies already on my system and I just need to know how to point VS at them? I'm stumped.
BTW: I was going to try uninstalling and reinstalling VS, but the installer fails with some very cryptic error message when I try to uninstall.
TIA for any help, and Happy Holidays to all!!!
I did a Repair using the .NET 3.5 SP1 SDK distributable, and I believe that this solved the problem. I thought at first that it didn't (as I say in prior comments) because I was looking for the files to show up in the v3.5 assembly directory. The missing files actually go in the v3.0 assembly directory. I later brought up one of the sample projects in VC and noticed that the symbols were now resolving, and sure enough, the missing .dll files were now present.
So I guess that the .NET SDK installer that ships with VS somehow didn't install these .dll files. It took doing a Repair on the SDK to fix the problem.
I'm a happy camper now!
In addition to change the target framework to 4.0, you also need to:
Add a reference to System.Workflow.Runtime
Add a reference to System.Workflow.ComponentModel
There's no assembly named System.Workflow in .NET 3.x: the WF assemblies (in 3.x) are:
System.Workflow.Runtime
System.Workflow.ComponentModel
System.Workflow.Activities
System.WorkflowServices (3.5)
You should be able to find all these assemblies in the GAC, and reference them via the Add Reference dialog, .NET tab.
It's possible System.Workflow is a (badly named) SharePoint-specific DLL, in which case, sorry, the above won't help... try the SharePoint install directory or SharePoint SDK install directory. Are the project templates you're using SharePoint templates, or the ones from File > New Project > Visual C# > Workflow?
I have a same problem, and solved it. The reason is your project's target .net framework not include this assembly (it's maybe .net 3.5 client profile or 4.0 client profile). The solution is very simple: set the target framework of your project to .NET Framework 3.5 or 4.0.
It work for me.
Please find it in C:/Windows/Assembly/GAC_MSIL
All the DLLs are Present there..
Also If U donot Find it then do the Following
Right Click Project->Application->Target Framework-> .Net Framework 4.0
It should show Up then.