I have a C# .NET Framework project which I sign using a .pfx file on my local system. In the .csproj file the following properties are set:
<PropertyGroup>
<SignAssembly>true</SignAssembly>
</PropertyGroup>
<PropertyGroup>
<AssemblyOriginatorKeyFile>keyfile.pfx</AssemblyOriginatorKeyFile>
</PropertyGroup>
This file is part of an open source project. I'm trying to create a pipeline which runs on certain commits. When I commit something, the original *.pfx can be installed using the password which is stored as a GitHub secret. The problem is that when forked repos make a pull request, the pipeline fails, because the GitHub secrets are not available to them.
Long story short, I found out that I can use public signing for this purpose. However, when I try to build my project using
msbuild src\TcBlackCore\TcBlackCore.csproj -t:Rebuild -p:DelaySign=false -p:PublicSign=true -p:Configuration=Release -p:Platform=AnyCPU -p:TreatWarningsAsErrors=true
I get the following error:
CS7102: Compilation options 'PublicSign' and 'CryptoKeyContainer' can't both be specified at the same time
I couldn't find any information on this error code except for one GitHub issue which mentions:
ERR_MutuallyExclusiveOptions CS7102
What are the mutually exclusive options here? The DelaySign should be set to the docs. And what should I do to get the public signing to work such that forked repos can be build?
> msbuild -version
Microsoft (R) Build Engine version 15.9.21+g9802d43bc3 for .NET Framework
The problem with public sign is that while the compiler applies a public key, is doesn't actually signs the assembly. It is like a 'mark' on the assembly.
In your case, you cannot use both CryptoKeYContainer and PublicSign at the same time because they are doing almost identical things, thus the compiler prompts the error.
for your purpose I would recommend using the DelaySign - as Microsoft docs states:
Use DelaySign - If you want a fully signed assembly. Use DelaySign
if you only want to place the public key in the assembly
For reference the tag is:
<DelaySign>true</DelaySign>
Related
I'm trying to log in using AWS Cognito by running the app after building it in Unity.
I couldn't log in properly, and when I tried debugging, I found the phrase "The type initializer for Amazon.AWSConfigs' thread an exception."
This error occurs when executing the following code:
Amazon.CognitoIdentityProvider.AmazonCognitoIdentityProviderClient provider =
new Amazon.CognitoIdentityProvider.AmazonCognitoIdentityProviderClient(new Amazon.Runtime.AnonymousAWSCredentials(), regionTable[REGION]);
The app itself is built normally, but there seems to be a problem with logging in using AWS.
(I found this error in the PC and oculus environment.)
Some of the answers told me to modify the Config file. But I couldn't find the Config file. The location of this file was also unknown.
I found this answer "https://github.com/aws/aws-sdk-net/issues/310" but I couldn't apply this for me.
I found this Document "https://docs.unity3d.com/kr/2021.1/Manual/upm-config.html#upmconfig" but the Config file didn't exist in this path. My environment is Mac.
additionally,
I use AWS SDK called aws-sdk-net45-3.7.193.0.
UnityInitializer.AttachToGameObject(this.gameObject);
Amazon.AWSConfigs.HttpClient = Amazon.AWSConfigs.HttpClientOption.UnityWebRequest;
In this code, my Project Cannot understand UnityInitializer, HttpClient, and HttpClientOption.
What else changes are needed in order to mitigate the above issue.
I solved this problem.
The problem was that I was using IL2CPP as Script backend.
Simply using Script backend as Mono is one way. But my project had to use IL2CPP.
In order to use IL2CPP and use the Unity project using AWS Cognito, it is recommended that you:
Use .NetStandard2.0.
Use AWS SDK that is compatible with .NetStandard 2.0.
I used Unity 2020.3.19f version to use .NetStandard 2.0.
If you are using a URP project and there is an error in URP due to downgrade of Unity version, it is recommended that you act as follows.
Enter the Package folder for that project
Open Manifest.json and Package-lock.json files
Change the Render Pipeline version to 10.8.1 (for 2020.3.19f1 version. I didn't experiment with other versions.)
Reference found to resolve this issue.
https://forum.unity.com/threads/issue-with-system-configuration-configurationmanager-get_appsettings-on-ios.1026877/#post-6656764
https://docs.aws.amazon.com/ko_kr/mobile/sdkforunity/developerguide/aws-unity-sdk.pdf
https://docs.unity3d.com/Packages/com.unity.render-pipelines.universal#10.8/manual/index.html
In the Validation Result that I get when readying my app for submission to the Microsoft Store (which my app "PASSED WITH WARNINGS"), I got this "Fail" under the "Package Sanity Test" section:
The code which contains such a call is:
private void myMapsHelpToolStripMenuItem_Click(object sender, EventArgs e)
{
System.Diagnostics.Process.Start("https://ramblingnotesofageezer.substack.com/p/map-o-matic-overview");
}
I am using that code due to the recommendation to do so here. How do I start a process from C#?
Is this truly a problem? If so, what should I use instead of the call to System.Diagnostics.Process.Start()?
I find it odd that it is classified as a failed part of the test, yet the overall results are that my app passed (albeit with warnings).
UPDATE
I checked out the link in the comment from Codexer, where it says, "Starting a utility can often provide a convenient way to obtain information from the operating system, access the registry, or access system capabilities. However, you can use UWP APIs to accomplish these sorts of tasks instead."
If this is the solution, do the UWP APIs have an equivalent to System.Diagnostics.Process.Start()?
UPDATE 2
I followed the steps in the answer, but the solution still doesn't compile, due to an error with this line of code:
await Windows.System.Launcher.LaunchUriAsync(uri);
In fact, even when I comment out the offending line, the project will no longer compile, but doesn't give me any information about how to solve the problem, just this:
I set the Package Management Format to PackageReference, and installed version 10.0.18362.2005 of Microsoft.Windows.SDK.Contracts, but it is complaining about needing a package reference...?!? I tried adding using Windows.System;
and using Microsoft.Windows.SDK.Contracts; but neither is recognized.
The package is installed for the project, as you can see here:
UPDATE 3
Regarding the "Must Use Package Reference" err msg, I have three questions revolving around what I see here:
The verbiage below Microsoft.Windows.SDK.Contracts says I can update versions of this package - should I?
I do not see a Reference to Microsoft.Windows.SDK.Contracts in my project's References, although it has been installed. Do I need to add one - if so, from where?
The context menu on my References affords me the ability to "Migrate packages.config to PackageReference..." should I do that?
If you were developing an uwp application, for opening open a web uri, it is recommended to use Launcher.LaunchUriAsync(Uri) method instead, this method starts the default browser to open the specified URI.
For example:
private async void button_Click(object sender, RoutedEventArgs e)
{
Uri uri = new Uri("http://www.google.com");
await Windows.System.Launcher.LaunchUriAsync(uri);
}
Update:
As Codexer mentioned, you could refer to this document to use uwp api in winform app.
I have created a winform project, its target framework is .Net Framework4.8. For earlier versions of .NET(.NET Core 3.x, .NET 5 Preview 7 (or earlier), or .NET Framework), you could refer to my steps.
1.Click Tools->NuGet Package Manager-> Package Manager Settings-> Change Default package management format to PackageReference. As follows:
2.Install the Microsoft.Windows.SDK.Contracts package, note that you need to install the appropriate version. Please check the corresponding version below. (Installation details: Right click Reference-> Manage NuGet Packages->Browse->Search Microsoft.Windows.SDK.Contracts->install)
10.0.19041.xxxx: Choose this for Windows 10, version 2004, version 20H2
10.0.18362.xxxx: Choose this for Windows 10, version 1903.
10.0.17763.xxxx: Choose this for Windows 10, version 1809.
10.0.17134.xxxx: Choose this for Windows 10, version 1803.
3.Run the project
I am attempting to build and use the MicoCharts project available here: https://github.com/dotnet-ad/Microcharts which is dependant on this SkiaSharp project available here: https://github.com/mono/SkiaSharp
The specific version I am attempting to use is 15.9.1 (the version that the nuget package downloads) which utilizes skia m59.
I need to build them myself and cannot use Nuget due to business restrictions, just use the package isn't an option for me.
I have built skia m59, SkiaSharp and MicroCharts but when I attempt to create a SKBitmap object I get an error when it attempts to initialize SkiaSharp.SKImageInfo. The error is as follows:
Unable to find an entry point named 'sk_color_get_bit_shift' in DLL 'libSkiaSharp'.
I had to make a few changes to the base BUILD.gn to point to the correct file locations, for the windows SDK and the VC install. I enabled skia_use_gdi in the BUILD.gn and ran the following commands.
python2 tools/git-sync-deps
gn gen out/Release --args="is_debug=false is_official_build=true skia_use_system_expat=false skia_use_system_libjpeg_turbo=false skia_use_system_libpng=false skia_use_system_libwebp=false skia_use_system_zlib=false skia_use_icu=false is_component_build=true"
ninja -C out/Release skia
This process outputs a DLL I assumed is the same as the libSkiaSharp that the SkiaSharp project relies on. I add all my references and run, the project runs successfully until I attempt to create the SkBitmap object then it fails.
Either this DLL is not the correct DLL and I am misunderstanding something here or something in my process is wrong. I would love any help I can get as I am completely new to building these sorts of projects, I am a C# developer by trade.
This is not the same thing. SkiaSharp has a few other bits that it adds to the core skia. The output that you would have got is a skia.dll, which only part. Not sure how you got a libSkiaSharp from the skia target...
If you can't use SkiaSharp from NuGet.org (which is the supported case) you can follow this to build your own: https://github.com/mono/SkiaSharp/wiki/Building-SkiaSharp
You can also check out the Azure DevOps yaml: https://github.com/mono/SkiaSharp/blob/master/scripts/azure-pipelines.yml
Just set up your own DevOps job to use that and all the work will be done for you.
In this video from MSDN at the 3:34 second mark, the presenter shows how to append the Build ID to a nuget's version. In the MSBuild arguments, he specifies:
/t:pack /p:PackageVersion=1.0.$(Build.BuildId)
So, when the project is built by VSTS, the nuget assembly's revision number is using the build id.
I would like to do something similar. Instead of hard coding the 1.0 in the build definition, I'd like to retrieve that from .csproj file. I am using the new .csproj file which stores nuget information.
For example, I'd like to specify in the csproj:
<Version>0.0.1-beta</Version>
Then, VSTS would append the BuildID and generate the assembly version as 0.0.0.1-beta.49 (49 being the build id)
I ended up doing the opposite of what Shayki Abramczyk suggested.
I use a task called "Variables Task Pack". It can be found here (and is free at the time of this answer): https://marketplace.visualstudio.com/items?itemName=YodLabs.VariableTasks#qna
Using this task, I set two variable: $(BuildId) and $(ReleaseType). See the settings snapshots at the end of the answer.
Then, in my CSPROJ project file, I modified the nuget version to use the two environment variables. Here's a clip of the project file:
<PropertyGroup>
<Version>0.0.0.0$(BuildId)$(ReleaseType)</Version>
<FileVersion>0.0.0.0$(BuildId)$(ReleaseType)</FileVersion>
...
</PropertyGroup>
IMPORTANT: Notice the extra 0 in front of $(BuildId). I had to add that in order to build locally. Without it, the build failed with an incorrect version format error.
Now, after building, I get the buildid as my revision number and release type appended.
Here are the screen shots showing configuration of both variables.
You can create a Power Shell script that retrieves the version from csproj file, then add the version to a new environment variable with this command: Set-VstsTaskVariable
For Example:
$csprojId = $retrivedIdfromTheFile
Set-VstsTaskVariable -Name "CSPROJ_ID" -Value $csprojId
Now you can use the CSPROJ_ID variable on the MSBuild arguments:
/p:PackageVersion=$(CSPROJ_ID).$(Build.BuildId)
I have an Azure project in TFS that used to work well.
I've just get the latest version and rebuilt the project and now I get the following version:
Error 131 The XML specification is not valid: The 'schemaVersion' attribute is invalid - The value '2013-10.2.2' is invalid according to its datatype 'http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition:SchemaVersion' - The Enumeration constraint failed. D:\TFS_BOIRA\PROPPOSV3\BACKEND\ServiceLayer.Azure1\ServiceDefinition.csdef 2 125 ServiceLayer.Azure1
The same configuration in another computer works well.
I have checked the version of Azure Tools of both computers and we have different versions.
In my computer (Where I get the error) I have azure tools 2.3, whereas in the other computer where it works well the version is 2.2.
May it be a problem of azure tools versions?
When I add the role to the Azure cloud project, the assemblies:
Microsoft.WindowsAzure.Diagnostics
Microsoft.WindowsAzure.ServiceRuntime
are updated to version 2.3.0.0, and I need them in version 2.2.0.0.
Do I have to reinstall my azure tools to the version 2.2?
Thanks
In addition to Ingrid's answer, you need to get the latest schema version within the ServiceDefinition (.csdef) and ServiceConfiguration (.cscfg) files, and it is not good enough to just change the raw version value (e.g. 2.3), you also need the new version date:
2.3: schemaVersion="2014-01.2.3"
2.4: schemaVersion="2014-06.2.4"
<ServiceConfiguration serviceName="MyCoolCloudProjectName" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceConfiguration" osFamily="4" osVersion="*" schemaVersion="2014-06.2.4">
<ServiceDefinition name="MyCoolCloudProjectName" xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition" schemaVersion="2014-06.2.4">
You need to keep this in sync if you are working on two different machines. Either bring both up to 2.3 or revert. Keep in mind that as part of upgrading it may have changed config files which you haven't checked in yet.
Finally what it worked for me was reverting the version of Azure Tools, as #Steve Newton has said.
How to revert the version it tis explained here:
http://social.msdn.microsoft.com/Forums/en-US/8701b03a-804f-4953-9ea0-01064aa4dc16/downgrade-from-18-tools-to-17?forum=azuretfs.
What I did was:
1.Modify the .ccproj file: the following two tags changing 2.3 to 2.2.
< ProductVersion>2.2< /ProductVersion>
< CloudExtensionsDir Condition=" '$(CloudExtensionsDir)' == '' ">$(MSBuildExtensionsPath)\Microsoft\VisualStudio\v$(VisualStudioVersion)\Windows Azure Tools\2.2\< /CloudExtensionsDir>
2.Open the files ServiceConfiguration.Cloud.cscfg and ServiceDefinition.csdef and change the version there.
I have the same kind of error
[my config: java/eclipse or jenkins/azure eclipseplugin/azure sdk]
ServiceDefinition.csdef (2, 128): Error CloudServices051 : The XML specification is not valid: The 'schemaVersion' attribute is invalid - The value '2014-06.2.4' is invalid according to its datatype 'http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition:SchemaVersion' - The Enumeration constraint failed.
I had no error on my workstation using Eclipse or console but I got this error on my Jenkins instance. It was maybe a difference between SDK. I updated both ( jenkins and my workstation) with the same SDK version but I keep this error... :(
The only workaround I found to have a success build was to remove this attribute from ServiceDefinition.csdef root element.
<ServiceDefinition xmlns="http://schemas.microsoft.com/ServiceHosting/2008/10/ServiceDefinition" name="AzureDeploymentProject">
In my build I keep the following warning but the package is build with success.
ServiceDefinition.csdef: Warning CloudServices040 : The 'schemaVersion' attribute is unspecified. Please set the attribute to avoid this warning.