In VS 2010 there is an option to output a build to a cab file. I cant seem to find a way to do this in VS 2012. Does anyone know of a way? If I upgrade our VS 2010 project containing cabs to 2012 it doesn't support it.
This an "extended" task. Not something built in (as far as I know).
http://www.msbuildextensionpack.com/help/3.5.11.0/html/f7724cf2-0498-92d8-ba0f-26ca4772d8ee.htm
Cab Class
Members Example See Also Send Feedback
Valid TaskActions are:
AddFile (Required: NewFile, CabFile, CabExePath, ExtractExePath, NewFileDestination)
Create (Required: PathToCab or FilesToCab, CabFile, ExePath. Optional: PreservePaths, StripPrefixes, Recursive)
Extract (Required: CabFile, ExtractExePath, ExtractTo Optional: ExtractFile)
Compatible with:
Microsoft (R) Cabinet Tool (cabarc.exe) - Version 5.2.3790.0
Microsoft (R) CAB File Extract Utility (extrac32.exe)- Version 5.2.3790.0
Remote Execution Support: No
Namespace: MSBuild.ExtensionPack.Compression
Assembly: MSBuild.ExtensionPack (in MSBuild.ExtensionPack.dll) Version: 3.5.0.0
There's an option.
Look as my answer to this post, and you can find a basic msbuild defintion (.proj file).
How to setup building steps for CruiseControl.net from repository of the building project?
Related
I've been a linux/make guy and recently I'm learning to build UE5 engine from VS 2022. I need to figure out a CLI way to build it.
For example, I right click on one of the modules (not sure if it's the most proper name) and choose 'Build' then the build will start. I want to automate the procedure using CLI.
How can I find the corresponding CLI command for this manual operation?
I don't have access to the Unreal Engine source code and I don't know if Epic has done anything highly unconventional.
From your start menu launch the "Developer Command Prompt for VS2022". This is a shortcut file for launching the Windows command line with a batch file run to set up the PATH and other environment variables for the Visual Studio development tools.
Visual Studio project files (.csproj for C# and .vcxproj for C++ for example) are MSBuild files. (MSBuild was inspired by Ant, if that helps.)
Solution files (.sln) are a completely different format but MSBuild can build a solution file.
From the screenshot in the question I can see that the solution is UE5 which will be UE5.sln. I can also see that you want to build a C++ project. I'm guessing the project may be named BenchmarkTest (BenchmarkTest.vcxproj)?
MSBuild has a notion of targets. A target always has a name and it groups a set of tasks to be performed. (It's like a makefile rule in some respects but it's not the same.)
Solutions and projects created with Visual Studio support some standard targets. The 'Build', 'Rebuild', and 'Clean' menu items map directly to some of these targets.
Visual Studio solutions and projects support Configurations and Platforms. The standard Configurations are Debug and Release. The screenshot shows a non-standard configuration of Develop. The screenshot also shows a platform of Win64.
In the Developer Command Prompt, msbuild should be in the PATH. Try the following command:
msbuild --version
To build the solution with the default target (which is 'build') and the default configuration and platform:
msbuild UE5.sln
To run a 'clean':
msbuild UE5.sln -target:clean
The target switch can be shortened to -t.
The configuration and platform are passed as properties using the -property switch. The short form is -p. Multiple property switches can be provided and multiple properties, delimited by ';', can be provided in one property switch.
msbuild UE5.sln -t:rebuild -p:Configuration=Develop -p:Platform=Win64
or
msbuild UE5.sln -t:rebuild -p:Configuration=Develop;Platform=Win64
To build the BenchmarkTest project, specify the project file:
msbuild BenchmarkTest.vcxproj -t:build -p:Configuration=Develop;Platform=Win64
Can someone assist with the following error which i am getting while building SSIS project using msbuild. I am having Visual studio 2015 in the machine. Using MSBuild 14.0
"*
error MSB4041: Th e default XML namespace of the project must be the
MSBuild XML namespace. If the project is authored in the MSBuild 200 3
format, please add
xmlns="http://schemas.microsoft.com/developer/msbuild/2003" to the
element. If the proje ct has been authored in the old 1.0 or
1.2 format, please convert it to MSBuild 2003 format.
*"
I have gone through some articles online but couldn't find solution with this scenario.
*" I have gone through some articles online but couldn't find solution with this scenario.
I'm afraid the answer is negative. For now this scenario(build SSIS project using msbuild) is not supported.
Someone has post this issue in DC forum, see Support SSIS, SSRS, SSAS in MSBuild. So if you're trying to use azure devops for CI/CD process, please vote and track this issue to get notifications when there's any update. And if you're using other tools for CI/CD process, I suggest you open a new feature request to support SSIS building for stand-alone msbuild tools in local machine.
And here're two workarounds which may help:
1.Since you have VS2015 installed, instead of msbuild command, you can try using devenv command.
For VS2015, we can find devenv.exe and devenv.com in path C:\Program Files (x86)\Microsoft Visual Studio 14.0\Common7\IDE. Both devenv.exe and devenv.com works for this, but note: Using devenv.exe directly prevents output from appearing on the console.
So devenv.xxx ... xxx.dtproj /build can work to build the SSIS project.
2.We can find binary(Microsoft.SqlServer.IntegrationServices.Build.dll) of the SQL Server Data Tools in C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE. Then we can use msbuild UsingTask element to call the tasks defined in that assembly.
The core is to call DeploymentFileCompilerTask task for SSIS build in our custom msbuild target after defining this statement:
<UsingTask TaskName="DeploymentFileCompilerTask" AssemblyFile="C:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE\PrivateAssemblies\Microsoft.SqlServer.IntegrationServices.Build.dll" />
More details please refer to here and here.
Update:
If we have several Database projects and SSIS projects in same solution. Using command like devenv.com xx.dtproj directly will actually build all projects.
So I suggest we use command in this way:
Open Developer command prompt for VS
cd to solution directory
use command: devenv.com SolutionName.sln /Build Development /Project SolutionName\xxx.dtproj /ProjectConfig Development
This will only build the SSIS project actually.
In addition: If you see the message The project 'DatabaseProjectName.sqlproj' will close once model building has paused. If it doesn't affect your build, just ignore it. After my check if won't actually build Database project(the output of database project is empty) if we use command above.
I have a problem with the standard MSBuild.exe used on our Team Build server, the standard version used is in
"C:\Windows\Microsoft.NET\Framework\v4.0.30319", version 4.0.30319.18408 or
"C:\Windows\Microsoft.NET\Framework64\v4.0.30319" respectively (same version).
Using this version leads to Fake dlls not being generated in the same way as on our local development machines (i.e. some fake methods are missing on the server), resulting in broken builds (unit tests) on the TFS.
I updated the build definition template to use the MSBuild version located under "C:\Program Files (x86)\MSBuild\12.0\Bin" as it is more recent (version 12.0.30723.0), however, this results in an error MSB1025, System.Threading.Tasks.Dataflow, Version=4.5.9.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a not found.
Update
Further investigation - manually adding the System.Threading.Tasks.Dataflow.dll with the correct version number to the MSBuild directory results in a broken build with
Unsupported ToolsVersion 12.0
Manually setting the ToolVersion in the Microsoft.TeamFoundation.Build.Workflow.Acitvities.MSBuild element to "4.0" results in a broken build with
Cannot set unknown member "Microsoft.TeamFoundation.Build.Workflow.Activities.MSBuild.ToolVersion"
So... no real improvement.
Any ideas how to fix this?
Fakes is sensitive to the Visual Studio version. Try passing /p:VisualStudioVersion=12.0 to MSBuild arguments. Also avoid handling System.* assemblies manually.
I was using sandcastle to generate help for my project in visual studio 2008. When i change my project to visual studio 2010 and change the project .NET version to .NET 4.0 i got this problem with Sandcastel. I can't understand why sandcastel is using C:\Windows\Microsoft.NET\Framework64\v3.5\MSBuild.exe
and not
C:\Windows\Microsoft.NET\Framework64\v4.0\MSBuild.exe
thinking that i specified as framework version the v4.0.30319
Can anyone tell me how to resolve this issue?? Where to change the path of the msbuild.exe or some other solution ???
Generating reflection information...
[C:\Windows\Microsoft.NET\Framework64\v3.5\MSBuild.exe]
GenerateRefInfo:
MrefBuilder (v2.4.10520.1)
Copyright c Microsoft 2006
Info: Loaded 1 assemblies for reflection and 0 dependency assemblies.
MREFBUILDER : error : Unresolved assembly reference: System.Windows.Forms (System.Windows.Forms, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089) required by WLAEDInt
Last step completed in 00:00:01.2731
-------------------------------
SHFB: Error BE0043: Unexpected error detected in last build step. See output above for details.
The current version of Sandcastle does not support .NET 4 without some config hackery. There is a new version that should be available quite soon, expected to support .NET 4 out of the box.
Edit: the latest Sandcastle is available now; perhaps that will solve your issue, since it includes .NET 4 support.
I had the same problem today, and this post helped me resolve it: http://shfb.codeplex.com/Thread/View.aspx?ThreadId=214594
Solution summary:
Step 1:
Ensure you've got the latest Sandcastle patches, especially for VS2010, available at: sandcastlestyles.codeplex.com. As of today, it is 'Sandcastle May 2008 Patch Rev 3 '.
Step 2:
Add another supportedRuntime element to the 'MRefBuilder.exe.config' file that utilizes the RTM version of .NET 4.0:
<supportedRuntime version="v4.0.30319"/> <!-- 4.0 RTM -->
I still had the error after step 1, then step 2 finally fixed it.
I ran into this same problem with the latest version of the Sandcastle Help File Builder v1.9.1.0 with regards to the Microsoft.VisualStudio.TestTools.UITesting library.
I resolved it by copying the referenced UITest assemblies (buried in the Visual Studio directory) to the directory containing the documentation source. Then bingo the build worked for the Sandcastle Help File Builder.
In my case it was caused by a bad xml comment code item.
''' <code language="cs" title="Example #1" source="MISSING SOURCE FILE"/>
''' <code language="vbnet" title="Example #2" source="MISSING SOURCE FILE"/>
Error from LastBuild.log:
BuildAssembler : error : CodeBlockComponent: [T:FrozenElephant.Symbiotic.DatabaseTypesFactory] Unable to load source file 'G:\Dev\FrozenElephant\SymbioticORM\SymbioticUniversalTests\UniversalTestProject_CS\ExampleUnitTests\AbstractFactoryTests.cs'. Error: Could not find file 'G:\Dev\FrozenElephant\SymbioticORM\SymbioticUniversalTests\UniversalTestProject_CS\ExampleUnitTests\AbstractFactoryTests.cs'. [G:\Dev\FrozenElephant\SymbioticORM\Symbiotic.Docs\Help\Working\BuildTopics.proj]
I've just upgraded a project from VS2008 to VS2010 but I'm still targeting the 3.5 framework.
In my project file I have a custom task to run SGEN to generate my XmlSerializers.dll. However the version of sgen being run targets the 4.0 framework. As a result, when I run my application I get the error message:
"Could not load file or assembly 'XXXX.XXXX.XmlSerializers' or one of its dependencies. This assembly is built by a runtime newer than the currently loaded runtime and cannot be loaded."
The Sgen task looks like this:
<Target Name="AfterBuild" DependsOnTargets="AssignTargetPaths;Compile;ResolveKeySource" Inputs="$(MSBuildAllProjects);#(IntermediateAssembly)" Outputs="$(OutputPath)$(_SGenDllName)">
<!-- Delete the file because I can't figure out how to force the SGen task. -->
<Delete Files="$(TargetDir)$(TargetName).XmlSerializers.dll" ContinueOnError="true" />
<SGen BuildAssemblyName="$(TargetFileName)" BuildAssemblyPath="$(OutputPath)" References="#(ReferencePath)" ShouldGenerateSerializer="true" UseProxyTypes="false" KeyContainer="$(KeyContainerName)" KeyFile="$(KeyOriginatorFile)" DelaySign="$(DelaySign)" ToolPath="$(SGenToolPath)">
<Output TaskParameter="SerializationAssembly" ItemName="SerializationAssembly" />
</SGen>
</Target>
There's the ToolPath="$(SGenToolPath)". How do I make it run the version that targets 3.5?
There's a similar question here but it doesn't help me much.
I have solved this by manually configuring the ToolPath to point to the old (version 2.0.50727.3038) version of sgen.exe
On my machine, this is in: C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin
I changed the ToolPath attribute to be:
ToolPath="C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin"
and this solved the problem.
It seems, by default, it's running the new 4.0 framework version in: C:\Program Files (x86)\Microsoft SDKs\Windows\v7.0A\Bin\NETFX 4.0 Tools
Hope this helps somebody else.
MSBuild uses the registry to get the path to the v3.5 tools. The MSBuild tasks that require v3.5 SDK tools will fall back to the v4.0 path if the path to the 3.5 tools can't be identified - look at the logic used to set the TargetFrameworkSDKToolsDirectory property in C:\Windows\Microsoft.NET\Framework\v4.0.30319\Microsoft.NETFramework.props if you're really interested.
You can diagnose and fix this problem as follows:
Install Process Monitor and set up a filter to monitor registry access by msbuild (Event class: Registry, Process Name: msbuild.exe, all types of result).
Run your build.
Search Process Monitor for a RegQueryValue access matching "MSBuild\ToolsVersions\4.0\SDK35ToolsPath". Note that this could be be under either "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft" or "HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft".
If you have a look at this key in the registry, you'll see that it aliases another registry value, e.g. "$(Registry:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Microsoft SDKs\Windows\v7.1\WinSDK-NetFx35Tools-x86#InstallationFolder)"
Shortly after this, you'll probably see a "NAME NOT FOUND" result. If you look at where the expected key should be, you'll see that they don't match the key being requested (missing hyphens and possibly no key ending with "-86").
It should be clear what you need to correct. I chose to export the incorrect keys, edit the .reg file and run it to create the correct keys.
One cause of invalid registry entries could be a bug with the Microsoft SDK v7.1 installation:
http://connect.microsoft.com/VisualStudio/feedback/details/594338/tfs-2010-build-agent-and-windows-7-1-sdk-targeting-net-3-5-generates-wrong-embedded-resources
I found this to be the easiest way and it works with: <GenerateSerializationAssemblies>On</ GenerateSerializationAssemblies>
<SGenToolPath>C:\Program Files\Microsoft SDKs\Windows\v6.0A\bin</SGenToolPath>
The problem is $(SGenToolPath) isn't set by MSBuild. If you use $(TargetFrameworkSDKToolsDirectory) then it will attempt to resolve the path based on $(TargetFrameworkVersion).
Its helpful to make use of tags for printf() style debugging. Add the following temporally.
<Target Name="AfterBuild" DependsOnTargets="AssignTargetPaths;Compile;ResolveKeySource" Inputs="$(MSBuildAllProjects);#(IntermediateAssembly)" Outputs="$(OutputPath)$(_SGenDllName)">
<Message Text="SGenPath: $(SGenPath)" Importance="high"/>
<Message Text="TargetFrameworkVersion: $(TargetFrameworkVersion)" Importance="high"/>
<Message Text="TargetFrameworkSDKToolsDirectory : $(TargetFrameworkSDKToolsDirectory )" Importance="high"/>
#Craig - Did you manually install the 7.0A framework on your build machine. If so, your problem may be your registry settings and not msbuild. Take a look at LocalMachine -> Software -> Microsoft -> MSBuild -> ToolsVersions -> 4.0 -> SDK35ToolsPath and make sure the reg key that is referenced there is valid. (Hint: Make sure the -x86 is there only if the -x86 key exists.)