We have SQL CLR dll that we developed quite a long time ago that we have been using. Unfortunately it wasn't ever in our normal daily builds.We are going to be upgrade our sql server from 2008 R2 to 2014. So i opened the project and upgrade it to a visual studio 2013 project (we hadn't opened it for quite some time). I also upgrade the target framework from 3.5 to 4.5.1. Lastly i changed the target sql server version to 2014. I was able to build it locally. I then tried to add it to our TFS build and got the following error:
E:\Builds\8\TRSApps\Dev\Sources\Shared
Objects\Components\FrsSqlCLR\VB Code\FrsSqlCLR.vbproj (76): The
imported project "C:\Program Files
(x86)\MSBuild\12.0\bin\amd64\SqlServer.targets" was not found. Confirm
that the path in the declaration is correct, and that the
file exists on disk.
I was able to resolve the problem. I searched for "SqlServer.targets" locally and found it under the .net 3.5 framework folder (not under 4.x):
C:\Windows\Microsoft.NET\Framework\v3.5
I just copied it to the location it was looking for it above and it fixed the problems which leads me to my questions:
Is TFS looking for SqlServer.targets in the correct location? If so then why isn't SqlServer.targets there?
Is there something i need to install on the build machine?
Why is the file in the 3.5 framework folder and not in the 4.x framework folder
Though i was able to resolve it by copying it from the 3.5 framework folder it seem a kind of hacky solution. I want the details so in the future when we upgrade our tfs server i have all the details.
You need to install Visual Studio 2013 on the build server. Also Sql Server Data Tools for 2013.
Once you have them on the build server it should build as is.
Related
We are upgrading our TFS build system from 2012 to 2015, and are recreating our build machine. We setup the build service, installed necessary dependencies etc. The (legacy) XAML builds are working fine except for the following SGEN error:
SGEN: An attempt was made to load an assembly with an incorrect format: (location of compiled project .dll)
After much Googling and and reading a number of stack overflow articles, I am still at a loss. I referred to multiple pages including:
- SGEN: An attempt was made to load an assembly with an incorrect format
I have tried
Installing Windows SDK 8.1 (and 8.0), 6.1, SDK for Win Server 2008 .net 3.5
Installing .Net 3.5 to 4.6.1
Installing Visual Studio 2010, 2012, 2015
Changing the TFS Build XMAL template file setting MSBuildPlatform to x86 (Microsoft.TeamFoundation.Build.Workflow.Activities.ToolPlatform.x86)
Verified the Generate serialization stratgy setting is set to auto for all projects
Changed the Build definition MSBuildPlatform and 'configuration to build' settings to x86, but this generated multiple (unrelated) errors. Ultimately the compiled projects needs to run as x64.
Also
There is no sgen.exe in the C:/Program Files/.... although there are multiple in C:\Program Files (x86). I cannot confirm that there is an x64 version on the system at all, nor can I find where to install one.
Setting the build 'configuration to build' option to x86 is not an option: this needs to be compiled as x64
We are building a very large code base that is owned by a different team, so changing the .SLN or .csproj files is not really a good solution unless absolutely necessary.
The target platforms in the solution and project files were not correct. I believe in the process of resolving other issues, I had modified the project and solution files platform targets.
Since this upgrade was a trial run, we were able to run the upgrade again, which in effect rolled the code back to the last pre-upgrade set of code.
I am working on a conversion of tfs 2013 build definition, we were initially using tfs 2008.I have a new server with TFS2013 installed and working on Build definition for 2013 xaml (workflow) customization is completed. However i am facing an error when my TFS build in release mode for Any Cpu configuration, but its fine when i use debug mode. I have tried looking many articles and unable to find any solution kindly help me here. This is fine in my local machine but happens only in the server.
Project and details
1) project is .net framework 4.0
2)Default configuration is "Any Cpu"
3)TFS 2013 server is 64 bit, windows server 2008 r2
Build Definition
Configuration : Any CPU|Release
MsBuildPlatform : x86
Error:
SGEN: An attempt was made to load an assembly with an incorrect format: C:\Windows\Microsoft.Net\assembly\GAC_64\System.Data\v4.0_4.0.0.0__b77a5c561934e089\System.Data.dll.
Warning:
C:\Program Files (x86)\MSBuild\12.0\bin\Microsoft.Common.CurrentVersion.targets (990): The reference assemblies for framework ".NETFramework,Version=v4.0" were not found. To resolve this, install the SDK or Targeting Pack for this framework version or retarget your application to a version of the framework for which you have the SDK or Targeting Pack installed. Note that assemblies will be resolved from the Global Assembly Cache (GAC) and will be used in place of reference assemblies. Therefore your assembly may not be correctly targeted for the framework you intend.
I have installed windos 8 SDK (Tools only)
and Windows framework 4 x64 as x86 version is failing
The folder C:\Program Files\Microsoft SDKs\Windows has v7.0 folder
C:\Program Files (x86)\Microsoft SDKs\Windows has v8.1A folder
where as my local machine has many versions inside the windows folder in above path
List of related articles which i have checked,but couldn't find a solution
http://seravy.wordpress.com/2012/10/25/installing-net-4-5-and-not-windows-sdk-8/
http://blogs.msdn.com/b/windowssdk/archive/2009/09/16/windows-7-sdk-setup-common-installation-issues-and-fixes.aspx
Running MSBuild fails to read SDKToolsPath
http://dukelupus.wordpress.com/2008/02/05/task-failed-because-sgenexe-was-not-found-solution/
How do I fix the Visual Studio compile error, "mismatch between processor architecture"?
TFS 2010 creating .Net 4.0 XmlSerializers DLL for .Net 3.5 Application
So what should i do to fix this error ?
You need to install the targeting packs (aka SDK, aka Developer pack) for the .NET Framework version you are targeting. You can download them all from http://blogs.msdn.com/b/dotnet/p/dotnet_sdks.aspx
Specifically for your question and targeting .NET Framework 4.0, you want Windows SDK for Windows 7 and .NET Framework 4 Sounds like you grabbed the Windows 8 SDK, which is not what you want for targeting .NET Framework 4.0.
This is not a very good answer (but in case someone comes across it like me), and does not provide insight into why it is occurring. But turning off "Generate the serialization assembly" on the offending project does allow for the build to work in my case.
Start up times will be slower, as serialization will occur at runtime instead now.
You simply need to see what framework you are using and then what debug mode you are using.
In my case i was using framework 4.0 and Build mode target framework "any cpu" but after searching around i found that i need to upgrade my .Net framework from 4.0 to 4.5 and i have to build my solution from "any cpu" to x86 framework because i had Windows 7 SPI with x86 architecture.
Here are some images what i have done to solve this error.
I encountered this error (albeit for a newer .NET framework version, v4.5.1, not v4.0 as in the original question) when trying to build my application on a build server.
The combination of the following two conditions was responsible for the error:
In Visual Studio, on the Project Properties page, on the Application tab, the "Target framework" was set to ".NET Framework 4.5.1";
On the build server, in folder C:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework, a folder named v4.5.1 was not present. (Other folders with version numbers, including v3.5, v4.0, and v4.5, were present.)
This missing folder was the cause of the "The reference assemblies for framework ... were not found" warning, which in turn lead to the "assembly with an incorrect format" error.
The fix was to install Windows Software Development Kit (SDK) for Windows 8.1 on the build server. In the install wizard, in the "Select the features you want to install" step, I unchecked all boxes except for the one for ".NET framework 4.5.1 Software Development Kit".
Running that install caused the missing v4.5.1 folder in the Reference Assemblies\Microsoft\Framework.NETFramework folder to be created, and the build to run successfully.
I am reluctant to answer because you say you have already done this, but every time I have struggled with the error message you quote, it has been the MsBuildPlatform setting. It absolutely has to be set to "X86". Are you sure the setting is being set..?
I have migrated a VS2008 solution to VS2013. My solution contains VC++ projets.
I have set the tools platform to v120_xp for each project
My solution compile on my computer and compile on my builds server in VS2013
My builds server is a Windows2008 R2 with VS2008, VS2010 and VS2013 and a build controler of TeamFoundationServer 2010.
When i launch the build with the build controller, the build fails with :
The imported project "C:\Program Files
(x86)\MSBuild\Microsoft.Cpp\v4.0\V110\Microsoft.Cpp.Default.props" was
not found. Confirm that the path in the declaration is
correct, and that the file exists on disk.
In the V110 directory this file doesn't exist but it exist in the V120 directory.
I have checked the registry :
HKLM\SOFTWARE\Microsoft\MSBuild\ToolsVersion\12.0
the VCTargetPath are corrects
Have you an idea to help me?
I have edited the registry key
HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft\MSBuild\ToolsVersions\12.0\11.0
and
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\12.0\11.0
to use the V120 directory
Now my server build the solution, but i don't understand why MSBuild use the key
ToolsVersions\12.0\11.0 and not the key ToolsVersions\12.0\12.0
Parhaps it's due to the v120_xp platform toolset
The true answer is that MSBuild subtracts 1 from the .sln Visual Studio Version. Since you do not have VS 2012 install or you have not installed it, the v11.0 folder is not found. It is all explained by Sayed Ibrahim Hashimi:
http://sedodream.com/PermaLink%2cguid%2ca5894bad-f2a1-441a-a5b2-74f16c6cf8aa.aspx
I came across the same problem in 2015 though, with Windows 10 and Visual Studio 2015 RC (fresh install)
To correct the issue I tried several solutions based on my research ie installing "VS Windows SDK" which didn't do anything different to resolve my problem, I then on another recommendation installed GitHub in order to download MSBuild which is now excluded from VS, I ultimately downloaded and installed "VS Tools for Windows 10" this didn't give me the same error in the end, without having to change registry keys
Installing VS 2012 on your build server should create the necessary targets files for you.
I was able to get past this by changing $(VCTargetsPath) to $(VCTargetsPath12) in the project file.
This feels like a temporary workaround rather than a permanent solution, since once we move to the next version of Visual Studio we'll have to find all the references to $(VCTargetsPath12) and replace with the new target path.
I currently work on a MVC 4.0 project that was upgraded to MVC 5.0 using the official guide.
I use Visual Studio 2012 locally and a publish profile was created for the project.
Locally I call msbuild via the Visual Studio developer command prompt using: msbuild /m /p:Configuration=Dev;DeployOnBuild=true;PublishProfile=Dev my-solution.sln
All projects in the solutions do have a Dev configuration and there is a web.dev.config.
The command line on the server is the same.
So far the difference is that on the server only the visual studio shell is installed (not the full) and we cannot install the full instance of VS2012 on the server.
Also, seeing on the install of TFS on the server, I discovered that only v9.0 target files were installed (Visual Studio 2008). Copying Visual Studio 2012 target files do not fix this problem.
I see 2 solutions so far but searching for a third.
Install full Visual Studio 2012 instance
Update csproj to include a target transformConfigFiles (basically copy and paste the content of the "Microsoft.Web.Publishing.targets" section) or import the file via a declaration inside of the .csproj
Would there be a third solution available?
It is pretty common to install full Visual Studio on your build server. As of VS 2012 you couldn't even run Unit Tests in your build without VS installed.
I'd suggest installing VS and seeing if that fixes the issue.
I just updated TFS from 2012 RC to 2012 RTM. The instal went just fine and everything is setup as it was. However now when I check-in files and the build process kicks off I keep getting an error relating to a missing System.EnterpriseServices.dll. Here is the full error:
CSC: Metadata file 'c:\Builds\1\MySite\bin\System.EnterpriseServices.dll' could not be opened -- 'Error importing module 'System.EnterpriseServices.Wrapper.dll' of assembly 'c:\Builds\1\MySite\bin\System.EnterpriseServices.dll' -- The system cannot find the file specified. '
Yes I have verified the file is in the bin, as as well I have removed then re-added it. One thing I suspect here is that I see the new TFS install added .NET 4.5 to the server, where before it did not exist... maybe that's a possible cause?? The application is a C# MVC4 website set to .NET 4.0.
I have also ran the 'Repair' on the TFS install and re-installed .NET 4.5. The project compiles and runs perfectly locally.
Any help is greatly appreciated!
Most of custom dlls problems comes from they are not in the right place, so try to put any custom dlls on the build server on the right place, see my answer there.
Upgraded TFS 2008 build definitions to TFS 2012 build defs using Upgrade Template, errors when queueing builds