I am attempting to a get a isolated build environment setup in my dev team.
The problem that I am presently hitting is a DotNet project which has a reference to a VB6 COM assembly.
The COM assembly is registered on the build system, but when I run msbuild against the sln I get the following error:
error MSB3303: Could not resolve COM reference "f630637a-718a-41c7-9c52-41f934dc4625" version 3.2. Object reference not set to an instance of an object.
The GUID for this assembly is correct, and if I load the solution up in Visual Studio it builds fine and generates Interop.* assemblies as required.
I do not wish to have the Visual Studio build as a requirement in the build steps.
How can I get msbuild from the command line to build the Interop assemblies the same as VS?
It appears that msbuild does not follow the project dependencies the same way as the IDE - as per this question
If I build the specific project that was failing before building the entire solution everything is good.
Related
We have an aspnet-core application which consists of several .net standard libraries, two aspnet-core mvc applications and, exceptionally, a .net framework console application.
These all build successfully, both in solution in Visual Studio, and also individually using msbuild/dotnet build commands.
We are now trying to implement continuous integration/build with VSTS.
We have found that the aspnet-core web applications build successfully, but the .net framework console application fails with multiple error messages like the following:
2017-12-24T07:20:26.4090447Z C:\Program
Files\dotnet\sdk\2.0.3\Microsoft.Common.CurrentVersion.targets(1988,5):
warning MSB3245: Could not resolve this reference. Could not locate the
assembly "Xxx.Core, Version=1.1.0.0, Culture=neutral,
processorArchitecture=MSIL". Check to make sure the assembly exists on disk.
If this reference is required by your code, you may get compilation errors.
[d:\a\1\s\WinApps\ListBuilder\ListBuilder.csproj]
C:\Program Files\dotnet\sdk\2.0.3\Microsoft.Common.CurrentVersion.targets(1988,5): warning MSB3245: Could not resolve this reference. Could not locate the assembly "Microsoft.EntityFrameworkCore, Version=2.0.1.0, Culture=neutral, PublicKeyToken=adb9793829ddae60, processorArchitecture=MSIL". Check to make sure the assembly exists on disk. If this reference is required by your code, you may get compilation errors. [d:\a\1\s\WinApps\TelemListBuilder\TelemListBuilder.csproj]
The console application follows the same folder structure as the web applications but seems unable to find any of the referenced packages.
Our Agent queue is Hosted VS2017.
We have two VSTS tasks: Restore and Build from the asp.net core build template.
If necessary we would be happy if we could exclude the console app from the build.
Since there are general .net framework project and .net core project and you want to build them together, you need to use Visual Studio Build task.
So, remove .Net Core Restore and .Net Core build tasks and add NuGet Tool Installer (4.3.0), Nuget restore and Visual Studio Build tasks (Visual Studio Version: Latest or Visual Studio 2017)
If you want to generate the deployment package during the build, you can specify MSBuild arguments like this:
/p:DeployOnBuild=true /p:WebPublishMethod=Package /p:PackageAsSingleFile=true /p:SkipInvalidConfigurations=true /p:PackageLocation="$(build.artifactstagingdirectory)"
We made the switch to Visual Studio 2017 and having trouble with our self-hosted build agent that gets its work from VSTS.
One VSTS-build step is building all solutions with "Visual Studio Build: Build Solution ***.sln" using "Visual Studio Version: Visual Studio 2017".
The following error happens for all our projects where "ASP.NET Core Web Application (.NET Core)" was the chosen project type.
C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Sdks\Microsoft.NET.Sdk.Publish\build\netstandard1.0\TransformTargets\Microsoft.NET.Sdk.Publish.TransformFiles.targets(54,5): error MSB4062: The "TransformWebConfig" task could not be loaded from the assembly C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Sdks\Microsoft.NET.Sdk.Publish\build\netstandard1.0....\tools\net46\Microsoft.NET.Sdk.Publish.Tasks.dll. Could not load file or assembly 'file:///C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Sdks\Microsoft.NET.Sdk.Publish\tools\net46\Microsoft.NET.Sdk.Publish.Tasks.dll' or one of its dependencies. An attempt was made to load a program with an incorrect format. Confirm that the declaration is correct, that the assembly and all its dependencies are available, and that the task contains a public class that implements Microsoft.Build.Framework.ITask.
Additional information:
From within Visual Studio 2017 the solutions built without any errors.
None of our projects include any .config transformations files (but do include .config files like web.config), still the error occurs.
Visual Studio 2017 Build Tools as well as full Visual Studio 2017 have been installed on the build server and e.g. .NET Core Class Libraries compile fine.
Installed .NET Core versions are identical between build server and developer machines.
The same errors also happen when using "MsBuild: Build Solution ***.sln" as a build step for all solutions and selecting "MSBuild: MSBuild 15.0".
The file mentioned as "Could not load file or assembly: C:\Program Files (x86)\Microsoft Visual Studio\2017\Professional\MSBuild\Sdks\Microsoft.NET.Sdk.Publish\tools\net46\Microsoft.NET.Sdk.Publish.Tasks.dll" does exist in the mentioned path.
No tasks are defined within the .csproj files.
Anyone got any insight as to what might cause this?
Have a look below:
https://github.com/aspnet/websdk/pull/174
I have reported the same behavior, and it turns out to be an issue only in the 64bit version of the MSBuild, switching back to the 32bit one worked for me, until this gets fixed.
Have a look at this link. It looks like the issue was previously fixed
https://github.com/Microsoft/msbuild/issues/1010
However, recently another change was made to MSBuild (referenced from above). My hunch is this 'downgrade' is causing the 'fix' to be ignored (wrong DLL ver is being used)
https://github.com/aspnet/Scaffolding/pull/321
Am using visual studio 2015 but whenever i begin a new ion ionic2 project an error
MSB3644 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.
After a research on the error i found out This link and This link but am using windows 10 on a 32 bit computer with program files folder and without the program filesx86 folder
Am not using any server and also a newbie to visual studio
I have also checked and
C:\Program Files\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0. is there
I also found out you need to add
msbuild -p:FrameworkPathOverride="C:\Program Files\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.
But am not sure where am supposed to add it
Can someone help me on this issue
But am not sure where am supposed to add it
Please run "Msbuild Command Prompt for VS2015"
Go to the folder of project
run the msbuild command
msbuild -p:FrameworkPathOverride="C:\Program Files\Reference Assemblies\Microsoft\Framework.NETFramework\v4.0"
MSDN docs Visual Studio Integration (MSBuild) state:
Building Solutions
Within Visual Studio, the solution file and project build ordering are
controlled by Visual Studio itself. When building a solution with
msbuild.exe on the command line, MSBuild parses the solution file and
orders the project builds. In both cases the projects are built
individually in dependency order, and project to project references
are not traversed. In contrast, when individual projects are built
with msbuild.exe, project to project references are traversed.
With my Visual Studio 2010, when building a .sln file with MSBuild from the command line, project to project references are all built, regardless whether they occur in the solution.
What did I miss here? Or are the docs plain wrong?
You are correct that msbuild.exe will sort out all project references whether or not they are part of the solution in contrast to building within Visual Studio 2010/2012/2013/2015 (and possibly later versions) where you will get a build failure if a referenced project is not part of the solution or built beforehand.
In short, yes, the documentation seems a bit off.
You can ignore the build of project to project reference by running msbuild Solution.sln /t:ProjectName /p:BuildProjectReferences=false this explain the sentence in msdn.
I have a visual Studion solution in which different SSIS packages are included along with class library project for custom component. The class library project has post build event which copies the .dll file into GAC and into PipelineComponent(C:\Program Files (x86)\Microsoft SQL Server\110\DTS\PipelineComponents). Now, when i open the visual studio solution and try to build class library project second time, it gives me an error possibly because the .dll file is already locked by visual studio which is used by other SSIS packages.
Now, how can i tell visual studio to not lock the .dll file? I tried to unload the SSIS packages, but it didn't work.
Please note that i want my class library project and SSIS packages in one solution.
You have a solution. Your solution contains 2 projects: one is a .NET class library project while the other is an SSIS project.
The problem you are running into is that you cannot overwrite the dll in the Pipeline Components folder as it is in use by the SSIS project. I ran into the same issue when I was developing custom components. I can't remember if it's the SSIS Toolbox that puts the lock on the file or a package actually using the component that locks it. I also don't recall what my final resolution was but I tried a variety of things.
My resolution
Exclude the SSIS project from your solution. You can either do this permanently by removing it from the solution or temporarily by unloading the project during your build phase. Ultimately, I went this route and created a separate solution with the SSIS project in it. This allowed me to unload the project in the other VS instance whenever I needed to redeploy the DLL. It also empowered me to put breakpoints in the SSIS project which allowed me to attach the VS debugger of the .NET and then debug into my custom component. Maybe they've fixed that since the 2005 days but at that point, you were stuck using 2 instances of VS to debug into your package.