When trying to build a wix4 project using a the new wix toolset provided like this:
wix build -d Configuration=Debug MySetup.wixproj
I get this error:
error WIX0048: The document element name 'Project' is invalid. A WiX source file must use 'Wix' as the document element name.
The project consists of 5 files. The wixproj file which I suspect will orchestrate the build. 3 wxs one that defines the basics from the setup and 2 which are filled up automatically by the HeatDirectory (defined in the wixproj). And last file is a xslt.
Those files have been migrated from wix3 using the VS 2022 HeatWave extension.
Did the migration miss some step or should I call the build in a different way?
To me looks like the wixproj file is missing some basic info to let the wix build command to work properly.
wix build is for building WiX source files without MSBuild. To build a .wixproj, use msbuild or dotnet build.
Related
I have several protobuf messages in a folder which I'd like to automatically convert into the respective header/cc files and then continue the compilation process inside of Visual Studio.
The best solution that I could comeup sofar was to define a Pre-Build Event through Propertise>Build Events>Pre-Build Event and specifying the following as the command:
$(SolutionDir)Dependencies\include\protobuf\bin\protoc.exe --proto_path=$(SolutionDir)Dependencies\include\messages\ --cpp_out=$(SolutionDir)Dependencies\include\messages\ message.proto message2.proto message3.proto
There are currently 2 issues concerning this solution :
I have to manually add each filename myself. How is it possible to make the filenames get picked automatically by VS2019? I tried %filename% macro, to no avail since it seems it returns the project file names only.
I also found out, these files are not generated each time I change the messages. even cleaning the projects, doesn't delete them, so I have to manually delete the generated files and try rebuilding the project again!
Other than resorting to a batchfile that can get called as a prebuild event, how can I achieve this inside Visual Studio without doing that?
I suggest you could refer to the following steps:
1,Modify the properties of the .proto file:Item Type:Custom Build Tool
2,Configure project properties: Properties -> Custom Build Tools -> General
command line:$(SolutionDir)Dependencies\include\protobuf\bin\protoc.exe --proto_path= .\proto %(Filename).proto --cpp_out=$(ProjectDir)protocpp
Description: protoc %(Filename).proto
Outputs: $(ProjectDir)protocpp%(Filename).pb.cc
Add Outputs to Item Type: c/c++ complier
And then you could try to build the .proto file.
Note: The newly added the .proto file also needs to select the operation of the Custom Build Tool
I created a new .Net Core 3.0 application as per the instructions in
https://aws.amazon.com/blogs/developer/net-core-3-0-on-lambda-with-aws-lambdas-custom-runtime/
However, as soon as I added a code library project dependency, the publish failed:
publish: C:\Program Files\dotnet\sdk\3.0.100\NuGet.targets(123,5): error : Ambiguous project name 'bootstrap'
I eventually realised that the error is down to the line in aws-lambda-tools-defaults.json:
"msbuild-parameters": "--self-contained true /p:AssemblyName=bootstrap"
This switch renames every assembly to 'bootstrap', which is utterly useless. The workaround is to rename the assembly name to 'bootstrap' in the .csproj file and remove the rename switch.
Is there a way to specify that only the one specific assembly should be renamed?
As the author of the mentioned blog post I think I should have suggested to set bootstrap in the project file instead of the command line option. The problem with the command line way is like you are seeing when you have multiple projects the command line tries to set all of the project assembly names to bootstrap.
I think I will update the blog post to remove the /p:AssemblyName=bootstrap and in the csproj file add <AssemblyName>bootstrap</AssemblyName> like the AWSProjectType element. That would get around your issue.
I have solution with n csharp projects and cpp project on top, this cpp provides interfaces and headers so those csharp ones can be used in other cpp solutions.
The build machine is configured to build csharp project with anyCPU architecture so it provides single assembly per build in Solution\bin\Release. For cpp the anyCpu is not available so I build project twice and store assemblies in Solution\bin\Release\x86 and x64 folders.
This is all to get it packaged in nuget as a single package with .targets file to ease consumption in other cpp projects.
Issue is that cpp project is looking for csharp asseblies using ResolveAssemblyReference and cannot find it, giving missleading message:
ResolveAssemblyReferences:
Primary reference "Implementation".
Could not find dependent files. Expected file "C:\Jenkins\Workspace\Solution\bin\Release\x86\Implementation.dll" does not exist.
Could not find dependent files. Expected file "C:\Jenkins\Workspace\Solution\bin\Release\x86\Implementation.dll" does not exist.
Resolved file path is "C:\Jenkins\Workspace\Solution\bin\Release\x86\Implementation.dll".
Reference found at search path location "".
I tried to alternate ResolveAssemblyReferences behaviour using command line properties, custom targets/properties, but without any luck. The parameters described in https://learn.microsoft.com/en-us/visualstudio/msbuild/resolveassemblyreference-task?view=vs-2017 seem to be computed during the build process and I cannot inject any value, which should be in this case something like $(OutDir)..
The one feasable solution seems to be copy c# dlls into each cpp folder, but I dont think it is the way to solve it properly.
Closes I got is by using /p:ReferencePath like below:
"C:\Program Files (x86)\Microsoft Visual Studio\2017\BuildTools\MsBuild\15.0\bin\MsBuild.exe" /p:BuildProjectReferences=false /p:Configuration=Release /p:DebugType=full /p:DebugSymbols=true /p:PlatformToolset=v120 /p:WindowsTargetPlatformVersion=8.1 /p:ForceImportBeforeCppTargets="C:\Jenkins\Workspace\Solution\Cpp.props" /p:OutDir="C:\Jenkins\Workspace\Solution\bin\Release\x86\" /p:Platform=Win32 /t:Build Interface\Interface.vcxproj /p:ReferencePath="C:\jenkins\workspace\Solution\bin\Release"
My custom Cpp.props does:
<Target Name="Output" BeforeTargets="ResolveAssemblyReferences">
<Message Text="AssemblySearchPaths: $(AssemblySearchPaths)" />
</Target>
and by adding /p:ReferencePath it got added to AssemblySearchPaths as second record, after {CandidateAssemblyFiles}; but it is still not finding those dlls
I am new for creation of NuGet Package. Somehow I managed to create NuGet Package as my solution. But, I am facing few problems in my solution. Based on regions, I am using the configuration file. for example, i am having following config files in my solution.
1) Service-AMR.config
2) Service-EUR.config
During build, i want to convert above files to service.config in AMR folder and same for another one. I have tried copy files task and failed.
Please help., Thanks in advance.
To simply rename a file name on the build agent, you could use cmd.exe in a command line task to rename files. Here's an example :
Arguments: String.Format("/c rename ""{0}"" ""{1}""","currentname.config","newname.config")
FileName: "C:\Windows\System32\cmd.exe"
WorkingDirectory: "C:\Windows\System32"
I'm trying to use the new VS Online Build process and, specifically, package my app as a NuGet package.
To do so I have to execute something like "nuget pack". My source code is in GitHub and there, under the root folder, I have a folder called .nuget with all necessary to do the packaging.
I've added to my build template a "Command Line" step with this parameters:
tool: C:\a\9ea8689c\myusername\myproject.nuget\nuget.exe
arguments: pack
Everything else is defaults, included working folder. This works. However when I've tried to replace the absolute path for something like ".nuget/nuget.exe" or .nuget/nuget.exe or even changing the working folder to .nuget and from there just type "nuget.exe" it repeatedly fails because it can't find the tool.
Am I missing something? Should the task work with relative paths?
You should use absolute paths leveraging TFS Environment Variables like TF_BUILD_BUILDDIRECTORY.
In a batch file it is something like
echo Launching my own NuGet copy
%TF_BUILD_BUILDDIRECTORY%\myproject.nuget\nuget.exe
This worked for me: $(BUILD.SOURCESDIRECTORY)\NuGet.exe.
Notice the dot instead of underscore. I have put my NuGet.exe in the main repository folder, in my case NuGet 3.5 Beta.