Since I needed its capability, I forked a NuGet package that was supposed to be able to enable me to process regular expressions in my build, the goal of which is to transform the .NET Framework version number into an environment variable, so that, for example, 4.7 becomes NET47. I am more than sufficiently familiar with regular expressions to make that happen, and the task runs perfectly when I call the assembly from a console program. It finds and loads the assembly, runs its Execute method, and sets the expected property values. However, when I try to run the task in a build, MSBuild reports as follows.
The "RegularExpressionMatching" task could not be loaded from the assembly RegexMatch.MSBuildTask, Version=1.0.0.7, Culture=neutral, PublicKeyToken=659f28f508fc4cd9, processorArchitecture=MSIL. 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. C:\Users\DAVE\Documents\Visual Studio 2013\Projects\WizardWrx_Libs\DLLServices2\ConsoleStreamsLab\ConsoleStreamsLab_4.7\ConsoleStreamsLab_4.7.csproj 81 5 ConsoleStreamsLab_4.7
My UsingTask element is as follows.
<UsingTask TaskName="RegularExpressionMatching"
AssemblyName="RegexMatch.MSBuildTask, Version=1.0.0.7, Culture=neutral, PublicKeyToken=659f28f508fc4cd9, processorArchitecture=MSIL" />
My Target block follows.
<Target Name="SecondMatch" AfterTargets="BeforeBuild">
<Message Text="TargetFrameworkVersion = $(TargetFrameworkVersion)" Importance="high" />
<Message Text="DefineConstants = $(DefineConstants)" Importance="high" />
<RegularExpressionMatching Input="$(DefineConstants)" Pattern="^(.*)(*;NET\d{1,2})(;*.*)*$" >
<Output TaskParameter="IsMatch"
PropertyName="IsMatchJiro" />
<Output TaskParameter="Match"
PropertyName="MatchJiro" />
<Output TaskParameter="Replacement"
PropertyName="ReplacementJiro" />
</RegularExpressionMatching>
The first two messages appear in the build log, exactly as expected, and shown, next.
------ Build started: Project: ConsoleStreamsLab_4.7, Configuration: Debug Any CPU ------
Build started 2017/07/24 15:14:29.
SecondMatch:
TargetFrameworkVersion = v4.7
DefineConstants = DEBUG;TRACE
C:\Users\DAVE\Documents\Visual Studio 2013\Projects\WizardWrx_Libs\DLLServices2\ConsoleStreamsLab\ConsoleStreamsLab_4.7\ConsoleStreamsLab_4.7.csproj(81,5): error MSB4062: The "RegularExpressionMatching" task could not be loaded from the assembly RegexMatch.MSBuildTask, Version=1.0.0.7, Culture=neutral, PublicKeyToken=659f28f508fc4cd9, processorArchitecture=MSIL. Confirm that the <UsingTask> 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.
Build FAILED.
Time Elapsed 00:00:00.00
========== Build: 0 succeeded, 1 failed, 1 up-to-date, 0 skipped ==========
Diagnostic Level Build Log is a previous attempt, run with the logging level set to Diagnostic. Though it gives a great deal more information, none of it sheds any light on the matter, so far as I can tell.
The assembly in question has a strong name, is installed into the GAC on the machine on which the build ran, and has no unusual dependencies, other than the three MSBuild assemblies.
I suspect the solution might be in the assembly references listed in the RegExMatch Solution, specifically Microsoft.Build.Utilities.v4.0, since I am unsure how that correlates with the build engine that runs in Visual Studio 2013, which reports itself as version 12 (although that may refer only to the version of Visual Studio with which it ships).
I would really like to get this working, so that I can do this task the data driven way, and eliminate hard coded settings. Once I have a proof of concept, I'll be delighted as well to submit a pull request to the original author.
I'll have my eyes open for good suggestions.
Did you import the project of the extensions? I haven't used the specific extensions you used, but when I used the MSBuildExtensions I had to add a set of lines to the effect of:
<Import Project="$(MSBuildExtensionsPath32)\Microsoft\VisualStudio\v10.0\WebApplications\Microsoft.WebApplication.targets" Condition="false" />
Only after this line was present was I able to acess the targets and use the extensions.
Related
I wanted to Publish a WinForm (.Net framework) as an executable (JUST 1 File). I had tested different ways of doing it.
I had tried
dotnet publish -r win-x64 /p:PublishSingleFile=true /p:IncludeNativeLibrariesForSelfExtract=true --output ../result
Error: C:\Program
Files\dotnet\sdk\5.0.302\Microsoft.Common.CurrentVersion.targets(3746,5):
error MSB4062: The "Microsoft.Build.Tasks.AL" task could not be loaded
from the assembly Microsoft.Build.Tasks.Core, Version=15.1.0.0,
Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a. 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.
[C:\RPIC\PICDashboard\PICDashboard\PICDashboard\PICDashboard.csproj]
and
msbuild /t:Publish /p:PublishSingleFile=True /p:IncludeNativeLibrariesForSelfExtract=True /p:SelfContained=True /p:Configuration=Release /p:Platform="Any CPU" /p:RuntimeIdentifier=win-x64 /p:OutputPath=../result
msbuild works without error but it produces many files as what's in the Debug and Release folder. It also give me a warning
C:\RPIC\PICDashboard\PICDashboard\PICDashboardSetup\PICDashboardSetup.vdproj.metaproj : warning MSB4078: The project file "PICDashboardSet
up\PICDashboardSetup.vdproj" is not supported by MSBuild and cannot be built.
I had also tried
dotnet msbuild -target:Publish -property:PublishSingleFile=True -property:IncludeNativeLibrariesForSelfExtract=True -property:SelfContained=True -property:Configuration=Release -property:RuntimeIdentifier=win-x64 -property:Platform="Any CPU" -property:OutDir=../result
Error: C:\Program
Files\dotnet\sdk\5.0.302\Microsoft.Common.CurrentVersion.targets(3746,5):
error MSB4062: The "Microsoft.Build.Tasks.AL" task could not be loaded
from the assembly Microsoft.Build.Tasks.Core, Version=15.1.0.0,
Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a. 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.
[C:\RPIC\PICDashboard\PICDashboard\PICDashboard\PICDashboard.csproj]
Is there any way that allows me to publish WinForms as a single exe?
"Any way" - yes, though I can't say "always"/"for all" applications and its dependencies.
Also, the following is done in Visual Studio (not dotnet cli - I haven't tried) with a trivial "Hello World" Windows Forms app (no external dependencies)
In your Application Build properties -> Release Configuration set Debugging information to None
In your Publish Settings
Result (in the bin\Release\net5.0-windows\publish\ folder set above):
Running an awesome app :)
Hth...
Which IDE version are u using. You cam choose produce single file in publish setting (1click publish method for vs2019)
I have created a C# CustomActions project to use in wix to create an installer. All I have is the sample project and a sample wix project that references it. And I created an app.manifest in the C# project.
Example simple program
What I get is:
1>------ Build started: Project: SetupProject1, Configuration: Debug x86 ------
1> C:\Program Files (x86)\WiX Toolset v3.11\bin\candle.exe -dDebug -d"DevEnvDir=C:\Program Files (x86)\Microsoft Visual Studio\2019\Professional\Common7\IDE\\" -dSolutionDir=C:\src\WixTest\ -dSolutionExt=.sln -dSolutionFileName=WixTest.sln -dSolutionName=WixTest -dSolutionPath=C:\src\WixTest\WixTest.sln -dConfiguration=Debug -dOutDir=bin\Debug\ -dPlatform=x86 -dProjectDir=C:\src\SetupProject1\ -dProjectExt=.wixproj -dProjectFileName=SetupProject1.wixproj -dProjectName=SetupProject1 -dProjectPath=C:\src\SetupProject1\SetupProject1.wixproj -dTargetDir=C:\src\SetupProject1\bin\Debug\ -dTargetExt=.msi -dTargetFileName=SetupProject1.msi -dTargetName=SetupProject1 -dTargetPath=C:\src\SetupProject1\bin\Debug\SetupProject1.msi -out obj\Debug\ -arch x86 -ext ..\WixTest\bin\Debug\WixTest.CA.dll Product.wxs
1>candle.exe(0,0): error CNDL0144: The extension '..\WixTest\bin\Debug\WixTest.CA.dll' could not be loaded because of the following reason: Could not load file or assembly 'file:///C:\src\WixTest\bin\Debug\WixTest.CA.dll' or one of its dependencies. The module was expected to contain an assembly manifest.
1>Done building project "SetupProject1.wixproj" -- FAILED.
1>
========== Build: 0 succeeded, 1 failed, 1 up-to-date, 0 skipped ==========
Any idea what else I need to do?
Yes, I had a look - please try this:
Please remove the reference to WixTestCA, leave WixTest in there. You don't need a direct reference to the WixTestCA file. You need a project reference instead.
Add your company name or something (anything will do) to the attribute Manufacturer.
Add After='InstallInitialize' to the Custom element to indicate scheduling inside the InstallExecuteSequence for the custom action in question.
Here are the snippets with injected changes:
The Product element:
<Product Id="*" Name="SetupProject1" Language="1033" Version="1.0.0.0" Manufacturer="Add Company Name here" UpgradeCode="ADD-VALID-GUID-HERE">
The Custom element (custom action):
<Custom Action='LicenseInfoCustomAction' After='InstallInitialize'>NOT Installed</Custom>
I built a complete Xamarin From application. When I change build mode to Release I get this error message:
Severity Code Description Project File Line Suppression State
Error The "LinkAssemblies" task failed unexpectedly.
Mono.Linker.MarkException: Error processing method: 'System.Void
Microsoft.Extensions.Primitives.InplaceStringBuilder::Append(System.String,System.Int32,System.Int32)'
in assembly: 'Microsoft.Extensions.Primitives.dll' --->
Mono.Cecil.ResolutionException: Failed to resolve System.Void
System.Runtime.CompilerServices.Unsafe::CopyBlockUnaligned(System.Void*,System.Void*,System.UInt32)
at Mono.Linker.Steps.MarkStep.HandleUnresolvedMethod(MethodReference
reference) at Mono.Linker.Steps.MarkStep.MarkMethod(MethodReference
reference) at
Mono.Linker.Steps.MarkStep.MarkInstruction(Instruction instruction)
at Mono.Linker.Steps.MarkStep.MarkMethodBody(MethodBody body) at
Mono.Linker.Steps.MarkStep.ProcessMethod(MethodDefinition method)
at Mono.Linker.Steps.MarkStep.ProcessQueue() --- End of inner
exception stack trace --- at
Mono.Linker.Steps.MarkStep.ProcessQueue() at
Mono.Linker.Steps.MarkStep.ProcessEntireQueue() at
Mono.Linker.Steps.MarkStep.Process() at
Mono.Linker.Steps.MarkStep.Process(LinkContext context) at
Mono.Linker.Pipeline.Process(LinkContext context) at
MonoDroid.Tuner.Linker.Process(LinkerOptions options, LinkContext&
context) at
Xamarin.Android.Tasks.LinkAssemblies.Execute(DirectoryAssemblyResolver
res) at Xamarin.Android.Tasks.LinkAssemblies.Execute() at
Microsoft.Build.BackEnd.TaskExecutionHost.Microsoft.Build.BackEnd.ITaskExecutionHost.Execute()
at
Microsoft.Build.BackEnd.TaskBuilder.d__26.MoveNext() EClinicForDoctor.Android
After searching on the Internet, I find this solution which says:
The resolution to this issue is to make sure you have the latest supported Android SDK versions, and set the Target Framework to Use latest installed platform. It's also recommended that you set the Target Android Version to Use Target Framework Version and the minimum Android version to API 15 or higher. This is considered the supported configuration.
Thus I update Android SDKs, set Target Framework and set minimum Android version to API 15.
However, I still get the same error. Another solution says that I should update NuGet Packages. I found that the version of the package System.Runtime.CompilerServices.Unsafe is 4.3.0 and there is an update for this package. When updating the package, the error no longer appear but another problem occur. When the app deployed, it run and stop without any error message. The mobile just exit from application without showing any error message. This happens when the package System.Runtime.CompilerServices.Unsafe is on version higher than 4.3.0. I tried to remove the package and the same problem happens again. How can I solve this problem?
I've seen this issue popup at a few different locations now. There is some discussion going around it like here: https://github.com/xamarin/xamarin-android/issues/1196
This Github issue also lists some (possible) solutions, the one with the most positive feedback seems to be this one:
Here's a functioning workaround. It's hacky and ugly but works with
minimum fuss. Put this in an XML file and <Import> it in your Android
csproj file at the end. It works at least for System.Buffers
<!-- Workaround for https://github.com/xamarin/xamarin-android/issues/1162 -->
<Project>
<Target Name="ReplaceRefAssemblies" AfterTargets="_ResolveAssemblies">
<ItemGroup>
<ResolvedAssembliesFixedWindows Include="#(ResolvedAssemblies->Replace('\ref\','\lib\'))" />
<ResolvedAssembliesFixedUnix Include="#(ResolvedAssemblies->Replace('/ref/','/lib/'))" />
<ResolvedAssembliesFixed Include="#(ResolvedAssembliesFixedWindows)" Condition="#(ResolvedAssembliesFixedWindows) != #(ResolvedAssemblies)" />
<ResolvedAssembliesFixed Include="#(ResolvedAssembliesFixedUnix)" Condition="#(ResolvedAssembliesFixedUnix) != #(ResolvedAssemblies)" />
<ResolvedAssemblies Remove="#(ResolvedAssemblies)" />
<ResolvedAssemblies Include="#(ResolvedAssembliesFixed)" />
</ItemGroup>
</Target>
</Project>
Another uses the XML from above and says:
I've just copied the content from the link above and saved as UnsafeFix.xml file in the Android project folder.
Then just added: <Import Project="UnsafeFix.xml" /> at the end of android .csproj file, just before
Cleared everything, recompiled and it finally worked!
Finally I get the solution. One of the comments in the issue provided by #Gerald Versluis solve the problem:
I follow these steps of hongliyu2002
https://forums.realm.io/t/could-not-load-assembly-system-runtime-compilerservices-unsafe-during-startup-registration/974/4
Go to C:\Users%user%.nuget\system.runtime.compilerservices.unsafe\4.4.0, and
delete "ref" folder then make a copy of "lib" folder and rename the
copy back to "ref".
Cleanup all the "bin" and "obj" folders in the projects.
Rebuild and run..
This simple workaround , works for me :) My current version is
Xamarin.Forms 2.5.1.444934
I am trying to publish or package our webrole into Azure, after migrating from SDK 2.5 to 2.7 (2.5 was working fine even though I am not sure if it is related).
This is the error I have from the Build in the Output window :
3>------ Build started: Project: MyProject.Azure, Configuration: Production Any CPU ------
4>------ Publish started: Project: MyProject.Azure, Configuration: Production Any CPU ------
4>C:\Program Files (x86)\MSBuild\12.0\bin\Microsoft.Common.CurrentVersion.targets(1697,5): warning MSB3270: There was a mismatch between the processor architecture of the project being built "MSIL" and the processor architecture of the reference "msshrtmi, Version=2.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35, processorArchitecture=AMD64", "AMD64". This mismatch may cause runtime failures. Please consider changing the targeted processor architecture of your project through the Configuration Manager so as to align the processor architectures between your project and references, or take a dependency on references with a processor architecture that matches the targeted processor architecture of your project.
4> Transformed Web.config using E:\Legacy\Main\Azure\MyProject.Front\Web.Production.config into obj\Production\TransformWebConfig\transformed\Web.config.
4>Done building project "MyProject.Azure.ccproj" -- FAILED.
4>
4>Build FAILED.
========== Build: 3 succeeded, 0 failed, 25 up-to-date, 0 skipped ==========
========== Publish: 0 succeeded, 1 failed, 0 skipped ==========
I have searched for an anwer and came up with this link http://blogs.msdn.com/b/narahari/archive/2012/03/30/windows-azure-package-creation-or-publish-fails-with-build-failed-message-in-visual-studio-output-window.aspx
where they state that it could be due to an OutOfMemoryException, and the fix is to build on a high end x64 system. I'm building on a core i7 16gig of ram really good computer so I don't think it comes from this. I also installed the windows 7 hotfix that fixes the emulator issue from largeaddressaware switch just in case but it did not help.
Thank you
Ok, I managed to solve the problem and here is how.
Actually, the issue is -even if totally not obvious- related to the diagnostics configuration.
What I did is increase verbosity for MSBuild output :
Tools > Options > Projects and Solutions > Build and Run > MSBuild project build output verbosity : Diagnostic
which uncovered this :
Failed to produce diagnostics extension's config for MyProject.Azure\diagnostics.wadcfgx.
Error : Value cannot be null. Parameter name: input
Then, the fix is to add :
<Setting name="Microsoft.WindowsAzure.Plugins.Diagnostics.ConnectionString"/>
in your ServiceDefinition.csdef and the correct implementations in your csfgs files.
After this, it all builds, packages and publishes.
Now, I am not sure if this question is a duplicate of Azure SDK v2.7 diagnostics issue is preventing publish/package because the title of the question in the link's post is already a step forward, and making the connection between this issue and the azure diagnostic configuration is really not that obvious, given visual studio's default minimal output.
Thanks everyone
I'm struggling with the following situation:
There is a bunch of projects (14 to be precise) in a VS2012 solution.
These projects are free from Code Analysis warnings and errors.
I would like to use the CodeAnalysisTreatWarningsAsErrors switch for our build server, so the build fails in case there are any CA issues. This is accomplished by setting the environment variable "CodeAnalysisTreatWarningsAsErrors" to "true". This flag is consumed by Code Analysis as parameter (see C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v11.0\CodeAnalysis\Microsoft.CodeAnalysis.Targets).
When building the solution from FinalBuilder (on the build server or on my machine) or from command line (through devenv.com), VS2012 output tells me that there are no Code Analysis warnings and no errors at all - but the build fails with no further reason.
I isolated the problem to the following pieces:
it is one single project that causes the fail. If i delete its binaries, the error can always be reproduced (this project uses the exact same .targets files and other environment stuff as the other projects)
if I set CodeAnalysisTreatWarningsAsErrors to false, the build succeeds (again, with 0 warnings and 0 errors).
The output from VS2012 is pretty poor and (according to my researches) there is no way to increase the verbosity level for devenv.com.
It looks like this:
1>------ Skipped Build: Project: xxxxxx_Test, Configuration: Debug x64 ------
1>Project not selected to build for this solution configuration
2>------ Build started: Project: xxxx.xxxx.Modules.Base, Configuration: Debug x64 ------
2> xxxx.xxxx.Modules.Base -> X:\xxx\x64\Debug\xxxx.xxxx.Modules.Base.dll
2> Running Code Analysis...
2> Code Analysis Complete -- 0 error(s), 0 warning(s)
========== Build: 0 succeeded, 1 failed, 12 up-to-date, 1 skipped ==========
FinalBuilder adds the return value:
devenv.com returned Error code : 1
Does anybody have any ideas what could cause the build to fail only when setting CodeAnalysisTreatWarningsAsErrors to true although there are no warnings and errors at all?
Resolved the problem:
That line of MSBuild-output made me curious and finally led to the right place:
The indirectly-referenced assembly '...dll' could not be found. This assembly is not required for analysis, however, analysis results could be incomplete. This assembly was referenced by: ...dll
Indeed, there was an assembly of third-party software that did not match the referenced version.
Obviously, that did not produce any error or warning at all, but, when activating CodeAnalysisTreatWarningsAsErrors, Code Analysis thought it's better to return with an error.
So, the solution was to (temporarily) use MSBuild with different verbosity-levels ('diagnostic' was too much, 'detailed' gave me still about 29.800 lines for code analysis of that single assembly-project, including the missing assembly name), digging through that stuff and finding the needle in the haystack...
Thanks to dario_ramos for pointing me towards the right direction!