We were using nant for building our project (10+Class Lib) and a Web Site which was based on the ASP.NET 2.0. Recently we are in the process of moving towards the ASP.NET 3.5. I searched in the net and found that nant doesn't support 3.5.
I am also looking in to option of migrating MSBuild.
Is the MS Build right candidate for this?
I heard people saying that MSBuild is slow? is it True?
With MS Build can I have a Single step build ? in nant all I will do is to call nant.ext and give a build file it will do a build and give me the output.
NAnt can easily be made to support .NET 3.5 - we use it here. Rather than claim credit, check this blog post.
Have a look at the Nant Site
.net Framework 3.5 is supported
In MsBuild you can have a single step build. Nant can be used with .Net 3.5 but is always behind the times (.Net 4.0 is soon to be shipped). Nant .86 beta1 has issues with x64 Windows Server 2003 (You will need to use a nightly build). I have used both and prefer MsBuild. For more details check out an older blog post I wrote Nant vs MsBuild
Related
I have made a project in VS2019. I have the same project in .NET Core and .NET Framework. I use a COM reference in my project. I would like to migrate these projects to Pi4.
A simple Hello World project (.NET Core) is running successfully on the Pi4 machine. However, when I try to run my project (.NET core or .NET Framework) it does not run on the Pi4. It says COM is not supported.
I tried to build the project using MSBuild in my Windows environment after looking for solutions in Google. I also see a similar error here. The error is: error : MSB4803: The task "ResolveComReference" is not supported on the .NET Core version of MSBuild. Please use the .NET Framework version of MSBuild.
The .NET Framework project also gives a similar error.
error MSB4028: The "ResolveComReference" task's outputs could not be retrieved from the "ResolvedFiles" parameter. Object does not match target type.
Does anyone have similar issues?
https://github.com/microsoft/msbuild/issues/3986
According to the above link. The employee of Microsoft is saying they can not give solution in the near future.
Set the Projects to x86 for them to build the Interop, the Interop created still could not be used in x64 runtimes.
Add the COM Reference to the Core project, Build it and you will get an Interop.YourCom in the bin/x86/core/debug folder.
Remove the COM reference, and re-add the Interop, it will be put into the Assemblies Dependencies, and MSBuild will work.
My MSB4803 was from a WIXInstaller project, for ADOX, and Microsoft.Office.Interop.Access.Dao
I stumbled upon this question many times and I experienced the same several times in different projects. It doesn't matter if it is Visual Studio 2019 or 2022 and the version of the build, unless you are working with the old MSBuild in a legacy environment, the COM Reference doesn't work. It is always safe to build it in the command line to understand if anything in the VS environment works. I don't truly understand why Microsoft let you make those references in the Visual Studio environment when they will not work nearly anywhere else.
There are some workarounds that might or might not work but if your code is already pointing at a COM library there is no much to do. You can install the NuGet package which is going to pass the build stage and remove the COM reference.
Install-Package Microsoft.Office.Interop.Excel -Version 15.0.4795.1001
The NuGet package has some differences at the types level that you will need to fix (the COM reference allows you to get specific types instead of objects from the cells values)
In any case, you will need the COM installed in the server, there is no workaround that issue.
I wouldn't say I like this error message or the link it shows on how to fix it, to be polite.... ;-);
I figured it out and thought as there are a lot of answers that are not helpful to share mine. What I did is update your command to force the use of msbuild.
dotnet msbuild -v:normal "FullOrRelativePathTo\MyProject.csproj" -p:Configuration=RELEASE
If that fails, try:
"C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Current\Bin\msbuild.exe" "PathTo\Project.csproj" /p:Configuration=RELEASE
I know I'm late to the party, but here is a workaround working for me when I want to use Office Interop in .NET (Core):
Create an empty .net Console app (I'm using Rider and .NET 7)
Build it with the default MSBuild (17.0 in my case at the time of writing)
Add Interop references to the project file (I don't use Nuget, only generate these in a dummy .NET Framework project while adding COM references to Office libraries), eg.
<ItemGroup>
<COMReference Include="Excel">
<Guid>{00020813-0000-0000-C000-000000000046}</Guid>
<VersionMajor>1</VersionMajor>
<VersionMinor>9</VersionMinor>
<Lcid>0</Lcid>
<WrapperTool>tlbimp</WrapperTool>
<Isolated>False</Isolated>
<EmbedInteropTypes>True</EmbedInteropTypes>
</COMReference>
</ItemGroup>
Change the solution MSBuild version to 4.0
Try to build the solution, but the project will not even load properly due to an outdated MSBuild version
Revert the MSBuild version to the default one
Build the project - success! (this is the magic part, I can't explain it :P)
Context: Consider a Visual Studio 2017 solution with number of projects targeting .NET 4.6.1; In TeamCity a MSBuild Runner is used for the build - A new .Net Core library project was introduced to this solution that obviously broke the build... The artefacts of this build are number of NuGet packages after successful NUnit test step.
My question is: Is it even possible and what is the best approach to have a mixed .NET Framework & .NET Core projects in the same solution?
Options:
I guess the obvious approach will be to separate the .NET Core code in pure VS .Net Core solution and use the TeamCity .NET Core build runner...
I am also exploring the option of creating a custom build script to execute from TeamCity that can handle the nature of both .NET package restore and build worlds... or may be this is not a good idea?
I'm trying to configure Visual Studio Online to continuously deploy my ASPNET 5 application to an Azure webapp as described in this tutorial from the Team Foundation Build docs: https://msdn.microsoft.com/Library/vs/alm/Build/azure/deploy-aspnet5
I have followed all the steps and everything is working great. By default this script deploys a build of my app that targets the full .Net 4.5.1 DNX so I decided to try and modify it to deploy for .Net Core.
The build script creates its deployment package by calling: msbuild.exe /t:Build,FileSystemPublish
After turning up log verbosity and reading through the relevant msbuild files I have learned the following:
The "Build" target ultimately uses dnx.exe to compile the project. Because the project.json file includes both dnx451 and coreclr TFMs this step produces build output for both frameworks - so far so good.
However, the FileSystemPublish target seems to only output an msdeploy package that targets the .Net 4.5.1 runtime. From the logs I could see executing the FileSystemPublish target ultimately issues a "dnu publish" command and in my cases passes "dnx-clr-win-x86.1.0.0-beta6" as the -runtime parameter. When I followed the breadcrumbs to find out where it was getting the value "dnx-clr-win-x86.1.0.0-beta6" from I eventually ended up in the "GetRuntimeToolingPath" task in Microsoft.DNX.Tasks.dll. This task seems to look in global.json to determine the correct runtime to use but strangely appears to internally override this value with "x86" and "clr" before creating the return string.
If I have interpreted things correctly, it seems that the FileSystemPublish target (in Microsoft.DNX.Publishing.targets) is essentially (indirectly) hard wired to use the x86, full .Net framework DNX when it produces its package output. At this point I am stuck for how to get this build process to produce a .Net Core package.
My question is why would FileSystemPublish be coupled to the x86 full .Net DNX and given this appears to be the case (unless I am mistaken) what is the recommended way to produce an msdeploy package for an ASPNET 5 app that targets .Net core?
EDIT:
For now I have a workaround. I can pass /p:RuntimeToolingDirectory="C:\Users\buildguest\.dnx\runtimes\dnx-coreclr-win-x64.1.0.0-beta6" as a parameter to msbuild.
This overrides the default logic in the GetRuntimeToolPath and forces it to use .Net Core. This works but feels like a hack so I'm leaving the question open for a better answer.
To publish Core CLR, you can pass the msbuild parameter 'PublishDNXVersion' as dnx-coreclr-win-x64.1.0.0-beta6.
msbuild <project>.xproj /p:deployOnBuild=true;PublishDNXVersion=dnx-coreclr-win-x64.1.0.0-beta6
From the Old Azure portal within the Web App section of it on the Dashboard page of your particular Web App.
[deep breath]
On the right hand side is a section that says "set up publishing with visual studio online". Clicking on that link will walk you through the necessary steps to set up continuous deployment from a visual studio online repository (either git or tfs based)
Since that is a mouthful, I have provided a link to a tutorial which walks you through the entire process: https://azure.microsoft.com/en-us/documentation/articles/cloud-services-continuous-delivery-use-vso/#step3
Had the same problem with .NET Core RC2-preview1 tooling. My solution: Add SDKToolingDirectory to my .xproj with a proper path to .NET Core installation:
<PropertyGroup>
<VisualStudioVersion Condition="'$(VisualStudioVersion)' == ''">14.0</VisualStudioVersion>
<VSToolsPath Condition="'$(VSToolsPath)' == ''">$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v$(VisualStudioVersion)</VSToolsPath>
<SDKToolingDirectory>C:\Program Files\dotnet</SDKToolingDirectory>
</PropertyGroup>
I had some luck with this by passing the following parameters into the Bundling step of my Visual Studio Online build process:
/p:Bundle64BitRuntime=true /p:BundleCoreClrRuntime=true
This causes my publish to leverage the 64 bit CoreCLR Runtime when it runs through msbuild.exe.
I figured this stuff out by digging through the Microsoft.DNX.Publishing.targets file (found at C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v14.0\Web) and looking for variables I could pass in as properties. Regarding runtime, this seems to be an interesting snippet:
<GetRuntimeVersion
Condition="'$(IgnoreDNXRuntime)' != 'true'"
RuntimeVersionOverride="$(PublishDNXVersion)"
TargetDNXVersion="$(_DefaultDNXVersion)"
RuntimeToolingVersion="$(RuntimeToolingVersion)"
Want64Bit="$(Bundle64BitRuntime)"
WantCoreClr="$(BundleCoreClrRuntime)">
<Output PropertyName="FinalPublishVersion" TaskParameter="RuntimeVersion"></Output>
</GetRuntimeVersion>
There's probably a little bit(?) of risk here in terms of future proofing your build routine against future changes to variables names. But, you know, beta software and all that :)
Good luck!
Background
We have a C++ solution that has been moved from VS2005 to VS2010 where the project files were targeting the .net framework 3.5 but since moving over to VS2010, all of the project files were showing that they were targeting the.net framework 4.0. I have since changed the .vcxproj files manually so that they are targeting the .net framework 3.5, using the method described in the Community Content on this link
The Problem
When I build these project files, manually or via an automated build, the output assemblies are still targeting the .net framework 4.0. I can tell this by using various methods described here. I also know that this is the case as I build and run the installer for this application. Once the application has been installed (which then shows as a service), I try to start the service on the target machine. This service will not start on a machine without the .net framework 4.0 installed. If 4.0 is then installed, the service will start, so this is another test that I can run that shows me that the application has a dependency on .net framework 4.0 which it should not.
The Aim
Ideally, I need to build this application so that the outputs are targeting the .net framework 3.5 instead of 4.0 so that it will actually run as it is supposed to! I have tried to use the 3.5 version of MSBuild as described in one of the answers given for this question here but got the same error that is described underneath that post.
Can anyone help with this? It's proving to be a right pain and I've been banging my head against the wall for over a week trying to get this sorted!
Thanks again in advance
Make sure you follow all the instructions as provided in the first link you posted.
For example,
Make sure you have Visual Studio 2008 installed on the build server.
Make sure you also change each project's "Platform Toolset" to v90.
Verify the project's framework version: "In Solution Explorer, right-click your project and then click Properties. In the Property Pages window, in the left pane, expand Common Properties and then select Framework and References. Verify that the new Framework version appears at the top of the right pane."
Is it possible to build a VS2008 solution (C# and VC++ projects) using the automated MSBuild built into TFS2010? When I niavely just run it, the build fails because the 2008 Solution file needs to be upgraded (and presumably so would the project files). Can I tell MSBuild 2010 to just build the 2008 files?
Does this blog post happen to work out for you? There are several ways you can get it working but just depends on your particular setup.
http://blogs.msdn.com/madhurig/archive/2009/11/25/building-vs2008-projects-with-tfs-build-2010.aspx