Mono Pkg-Config.exe Keeps Crashing? - c#

I'm new to Mono - thought I'd give cross platform a try - my main IDE is Visual Studio and so the process of building applications through the command prompt is a bit foreign to me.
I was following the Mono Basics tutorial, and have gotten to the point where it says Winforms Hello World. I copied the code provided and saved it to a .cs file (on the Desktop).
I then opened up a command prompt and pointed it towards the Desktop directory. I ran the command:
mcs hello.cs -pkg:dotnet
And the result was:
The console told me that it was a CS8027 error but nothing else.
I have 3 environment variables that I added, with no fix:
PATH -> path to mono\bin
PATH -> path to mono\lib\pkgconfig
PKG_CONFIG_PATH -> path to mono\lib\pkgconfig
This happens whenever I try to use pkg-config.exe (tried to use pkg-config.exe --list-all but the same problem arose).
I've checked other answers/questions about the CS8027 error but the solutions did not help - it still crashes every time!

Had the same problem. I had all the proper VC++ runtimes installed, but still crashed.
pkg-config.exe references librares (.dll) that are compiled in different versions of .Net. Your PATH (or pkg-config itself) might be referencing a different version than the one the .dll uses, or not have it at all.
pkg-config is a short-hand anyway. I fixed it by explicitly including the .dll I'm referencing using the proper version of .Net for me:
mcs hello.cs -r:"C:\Program Files\Mono\lib\mono\4.5-api\System.Windows.Forms.dll"

pkg-config is built with a different version of MSVC to Mono itself. You need the 32-bit VC++12 runtime installed for it to work. That ought to be included with mono.msi, as per https://github.com/mono/release/commit/8394dcc254510977c3e654abf916a48c6c6894fb
If you check the Windows event log, under Applications, you might get more information on what didn't work.

I had this problem, could help some.
D:\Code\Mono>mcs hello.cs -pkg:dotnet
error CS8027: Error running pkg-config. Check the above output.
I needed to download the following DLL:s from https://www.dll-files.com/
libiconv-2.dll
libgcc_s_sjlj-1.dll
libintl-8.dll
libglib-2.0-0.dll
Put them in C:\Program Files\Mono\bin
All DLLs should be 32 bits even if Mono was 64 bits.

In my system the problem was the empty space inside the path of install and how that is managed inside of the pc files.
A workaround is to edit the pc files to change the prefix entry to the short path. In my system:
prefix=C:/PROGRA~1/Mono
instead of
prefix=${pcfiledir}/../..

Related

How do I enable prediction when writing C# codes in Visual Studio Code? [duplicate]

I just downloaded Visual Studio Code and my Intellisense is not automatically working.
The two settings that control this seem to be set correctly:
"editor.quickSuggestions": true,
"editor.suggestOnTriggerCharacters": true,
I do get an Intellisense menu when i start typing and press "CTRL + Space", but this gives me a list of everything and not things specifically for my object.
What am i doing wrong?
If you have a workspace and for some reason have multiple folders you may need to 'help' omnisharp a bit. I initially had a big project and added a solution for it further on - ending up with TWO workspace folders (one to a startup project and one to the solution). After composing that setup I experienced only the first project to have intellisense working.
Solution to get intellisense working was to make sure omnisharp worked its way from the solution instead of the project:
Ctrl + Shift + p
Write "OmniSharp: Select Project" and press Enter.
Choose the solution workspace entry.
Inspiration gotten from 'swaner':
https://github.com/OmniSharp/omnisharp-vscode/issues/1889
Visual Studio Code's more advanced editing features (IntelliSense, refactoring tools, etc.) only work in C# files if you have a project.json file or *.sln file that VSCode is aware of. Open the folder (i.e. open the File menu and click Open Folder...) with the *.sln file or project.json and VSCode will attempt to find all project/solution files in the folder. If there are multiple projects, you may need to select one from the projects button on the right side of the status bar (bottom of the window).
From the VSCode website:
Selecting a project.json-file is opening a DNX-project and VSCode will load that project plus the referenced projects
Selecting a *.sln-file is opening a MSBuild-project. It will load the referenced *.csproj-projects and sibling or descendant project.json-files but no other project files that are referenced from the solution file.
Selecting a folder will make VSCode scan for *.sln and project.json files and VSCode will attempt to load them all.
If you are start your project with c#, then some time you haven't download extension.
Process by written
Ctrl + Shift + p.
Write "OmniSharp: Select Project" and press Enter.
Choose the solution workspace entry.
Then enable the c# extension for "OmniSharp : Project".
Process by image
Downgrading to 1.23.9 of the C# VS Code extension fixed the intellisense for me. So if nothing else is working for you, perhaps try installing an older version of the extension (doesn't necessarily have to be that exact one I mentioned). You can do this by selecting this option in VS Code:
As of the 0.5 version I have found that I need to close and re-open my working files to get some new intellisense information to start working for my own files. This usually happens after I have a file open that needs to use type information from another file I just created. Until I close and re-open them (within the editor) the intellisense doesn't always work.
Hopefully this is something that'll get fixed as the app matures.
Inorder to make the intelligence working, the Visual Studio Code extension OmniSharp should be there along with Mono. When you open a project/solution folder, the OmniSharp gets the project dependencies from either project.json or from the dotnet solution file (if the project/solution created with other versions of visual studio).
So, when you look at the omnisharp's output window after immediately opening the project/ solution folder, you may see the following lines
Starting OmniSharp server at 2017-9-18 09:26:44
Target: /Users/{username}/Source/{Your Solution Folder}/{Your Solution
file}.sln
OmniSharp server started wth Mono
Path: /Users/{username}/.vscode/extensions/ms-vscode.csharp-1.12.1/.omnisharp/run
PID: 5808
post that, you may see couple of lines coming up like below,
[info]: OmniSharp.MSBuild.MSBuildProjectSystem
Update project: {Your Project1 Name}
[info]: OmniSharp.MSBuild.MSBuildProjectSystem
Update project: {Your Project2 Name}
....
they mean that your projects are getting recognised by OmniSharp Extension.
If you get any error message informing you about timeout, please get into the settings of the Visual Studio Code, and add a configuration override like the one below:
"omnisharp.projectLoadTimeout": 200
I know it is too long to wait for 200 seconds. But don't worry, this won't stop you anymore working with project files. But, remember that the IntelliSense will be automatically available once all the projects in the folder are successfully loaded.
Feel free to extend the Timeout setting since it will help you getting intellisense even-though you are not getting it immediately.
Here is another link with the same solution: https://github.com/OmniSharp/omnisharp-vscode/issues/1585
Hope my information helps you! Enjoy your VSCode!
This case was for an existing project that was working fine before. Opened via the vs code "recent" history.
For dotnet core. I opened my project's *.csprog file, made no changes, and saved it via the vs code editor.
As soon as I saved, all of the intellisense stuff starting working again in my other files within that project.
Another troubleshooting strategy to try if none of the above works out is uninstalling Mono, which is unnecessary anyways if you're using .NET Core. I also experienced a sudden disappearance of Intellisense after pulling changes to one of our enterprise repos that included an upgrade from ASP.NET Core 2.0 to 2.1. Strangely, at the same time, Intellisense was working fine in another C# project repo running ASP.NET Core 2.2.
For the project in question, I was puzzled to see successful logs for each reboot of the Omnisharp server as well as perfectly clean builds and runs. The puzzlement increased as I compared these Omnisharp logs to those from the 2.2 project and found them effectively identical.
Upon uninstalling Mono, the one detail that changed is how Omnisharp started. Now it boots up from a shell script located at ~/.vscode/extensions/ms-vscode.csharp-1.19.0/.omnisharp/1.32.18/run. Previously, Mono itself was booting the server from the executable at ~/.vscode/extensions/ms-vscode.csharp-1.19.0/.omnisharp/1.32.18/omnisharp/Omnisharp.exe.
Other troubleshooting I attempted in this instance though to no avail:
dotnet clean / Deleting bin and obj directories
Updating launch.json to point at the proper /bin/Debug/netcoreapp2.1 build
directory
Wiping my local nuget cache
Restarting Omnisharp
Uninstalling and reinstalling VS Code, as well as bumping back a version from 1.33.1 as the breakage coincided oddly with the March 2019 update
Uninstalling and reinstalling the C# VS Code extension, as well as bumping back a version from 1.19.0 given other users' reports of said version interfering with Intellisense for certain projects*
Adding a global.json file at project root to override default utilization of latest .NET Core SDK (mine was 2.2.105) and run instead using 2.1.302 in concert with the project's version
Wiping/rebuilding the project .sln file
Specs: VS Code 1.33.1, C# Extension 1.19.0, MacOS High Sierra 10.13.6.
*NB: As it turns out, in another .NET Core 2.1 project with the same issues in VS Code as described above, uninstalling Mono alone did not fix things. I also did wind up needing to bump back the C# extension to v. 1.18.0 to recover Intellisense. Weird.
The issue I had was OmniSharp was an older version. I set the flag to update to latest version in Settings.json file. This ensures the extension is always the latest version.
"omnisharp.path": "latest"
And restarted VS code. That fixed it for me.
Simply reinstall the extension and restart the VSCode/PC.
I use Task Manager and kill the Visual Studio Code process, then restart Visual Studio Code, the intellisense shows and fixed.
I've had some good experiences in C# with this extension so far:
https://marketplace.visualstudio.com/items?itemName=jchannon.csharpextensions
This extension traverses up the folder tree to find the project.json or *.csproj and uses that as the parent folder to determine namespaces.
Try "Install Extension" from command Pallete - probably if C# intellisense is not there:
https://code.visualstudio.com/docs/customization/colorizer
if intellisense in not working for react js or javascript or node js this solution will help for windows
uninistall type script by typing npm uninstall -g typescript
install specific version of type script that is 3.3 by typing npm install -g typescript#3.3
add the typescript location in vscode by navigating to file > Preferences > settings > here search for edit in setting.json then add this path "typescript.tsdk": "/Users/yourusename/AppData/Roaming/npm/node_modules/typescript/lib"
settings.json should look someting like this
{
"editor.suggestSelection": "first",
"vsintellicode.modify.editor.suggestSelection":"automaticallyOverrodeDefaultValue",
"typescript.tsdk": "/Users/yourusername/AppData/Roaming/npm/node_modules/typescript/lib"
}
I was able to fix this by changing the Api Compatibility Level from .Net Standard 2.0 to .NT 4.x. You can find this setting on Project Settings / Player.
After that, intellisense started working again.
This is because of C# extension issue.
Reinstall the extension will work.
https://code.visualstudio.com/docs/editor/intellisense
https://marketplace.visualstudio.com/items?itemName=ms-dotnettools.csharp
I fixed this with a multiple project solution in .net5 / .net core 3.1 by
opening each project (not the sln folder) in VSCODE. This then prompts to add the resources/ .CSX? files to the project; enabling intellisense, per project. Finally close that window and reopen the solution folder and all works as expected.
See image
Add VSCode assets
Downgrading to 1.23.9 of C# for Visual Studio Code (powered by OmniSharp).
https://i.stack.imgur.com/VrdJl.png
After trying several things I looked at the OmniSharp logs only to realize that because I had two different sln files in my workspace. It had picked up the “other” one and thus wasn’t working. I deleted it, reopened vs code, and all is well again.
For me I had been working without internet for a long time. It had previously been working but then stopped. I closed+reopened VSCode with a stable wifi connection and the Output tab in VSCode popped up, displaying the the extensions were re-installing. After that it worked!
in my case , the extension wasn't enabled
I just had this happen (this being no code completion suggestions appearing). What resolved it for me was changing the VSCode Editor package in Unity to a previous version and then back to the current version.
For me, this was going from 1.2.0 to 1.1.3 and then back to 1.2.0. I believe removing and reinstalling 1.2.0 would have accomplished the same.
Window > Package Manager > Visual Studio Code Editor
I know this is probably the most obvious answer. But I had enough dealing with VS Code ridiculous bugs. You should be focusing on code, not the buggy IDE. Their documentation doesn't make it easy either to debug.
Steps for complete uninstallation:
Save your personalization files such as keybindings.json,
Just put it on GitHub or something so whenever you need have trouble with VS Code you simply just need to go to GitHub and copy-paste it.
Uninstall VS Code completely
When you uninstalled VS Code, it doesn't erase your extension files and some old settings. This is the cause of the re-installation ended up the same. Horrible move VS Code. For the list of the files that you must delete, you can check out this answer.
Go to their website and install the new one.
I hope this helps some people who are already had enough with the VS Code ridiculous bug.
In my case, the issue was not with VS Code settings. The error was due to a corrupted TEMP path configured in my PC's registry user profile environment settings.
I got this error from Help --> Toggle Developer Tools --> Console
The error was flagged in the console when I opened a new typescript file.
Unable to write file c:\Users\XXX\AppData\Local\Temp;C:\wamp64\bin\php\php5.6.25;C:\vufind-3.1.2\install.php\09cf49d8-af5b-42e9-8194-43f5b566be0f'
Obviously this path was corrupted. After updating the environment variables in registry settings, the VS code IntelliSense started working. Checking the console is a good start to find the root cause of this issue.
Earlier intellisense was working for Angular in VS-Code but for some reason (which I don't know) intellisense stopped working. I had extensions installed i.e. Angular Essentials and Angular Language Service etc. that were responsible for this intellisense and all that.
What I did?
I disabled the extensions, restarted VS Code and enabled them. It was all working fine as before.
If everything in VSCode is working ( No errors in output console, language server is working etc.) and built-in extensions are enabled. Still, if your IntelliSense is not working for normal .js files make sure variables are defined with a type identifier such as var d = new Date() or let d = new Date(). In my case, IntelliSense was not working for d = new Date() (No autocomplete for Date object 'd' APIs in this way) but started working fine when I specified a type before my variable names.
Download and install "Tool for Visual Studio 2019" as the C# extension under hood use the build tools: https://visualstudio.microsoft.com/downloads/
In my case, I had an extension installed (Explorer Exclude) to help me focus and hide certain files that I don't regularly work with within the Explorer.
I so happened to have disabled viewing *.sln, *.csproj and *.vsconfig files and folders, which apparently prevents VSCode from even knowing the file is there in the first place. Disabling these specific rules solved the problem instantly.
Took me ages to figure out... The more you know.
I solved it by uninstalling all SDK's (not sure if this is needed)
and installed 4.7.1 developer pack
win 10, vscode 1.63.2, unity 2020.3.25f1
I fixed this by installing .NET Framework 4.7.1 Developer Pack:
https://dotnet.microsoft.com/en-us/download/dotnet-framework/net471

NuGetFallbackFolder path suddenly "wrong" when on a German Windows

I think I understand a little more of what is happening so I rewrote my question... And it seems to be somewhat different from what I described first.
This time it happened when I started a new project of type grpc server.
The symptom still is the same:
"Der Fallbackpaketordner "C:\Programme (x86)\dotnet\sdk\NuGetFallbackFolder" wurde nicht gefunden."
Translation: The Fallbackfolder "C:\Programme (x86)\dotnet\sdk\NuGetFallbackFolder" was not found.
However it is not finding the "german path" (still on my "german" os).
And this is what I can reproduce - so I think I got it upside down when describing it last time...
Examining this further:
In my nuget.config this entry is generated:
<add key="Microsoft Visual Studio Offline Packages" value="C:\Programme (x86)\Microsoft SDKs\NuGetPackages\" />
If I delete it and change settings in the nuget packet managers packet sources it might get back...
While this SEEMS to right for a german OS "Programme (x86)" actually seems to be a ghost (sorry I do not know what the right term is). Because usually every reference seems to be redirected to" C:\Programm Files (x86)".
So even when I klick my way through Fileexplorer down into "Programme (x86)" - if I check the path in that "Path-Box" in Filexplorer it shows "C:\Program Files (x86)" instead.
But exactly this translation seems not to be working with nuget...
So who is setting this entry ? To me it seems like either it should be set to "Program Files" OR it should be translated which does not to seem to happen...
In Fileexplorer I can enter both paths into the path box. It does not matter if I enter "C:\Program Files (x86)" or "C:\Programme (x86)" - I always end up in the former. And that is where "\Microsoft SDKs\NuGetPackages" is actually residing. The problem is not that that path is not existing on my system. The problem is that somehow the german notation is used when generating that entry in my nuget.config but then the translation/redirection is not working or used in the nuget package manager...
Ah and I´m not sure if the project type does matter but just in case - this time it was a grpc service.
Visual Studio 2019 16.7.5
Core 3.1
It is your own issue about Net Core on your German PC. And C:\Program Files\dotnet\sdk is the system default location about VS. The default address is in English, not in German and we cannot change that.
The Fallbackfolder "C:\Program Files\dotnet\sdk\NuGetFallbackFolder"
was not found.
The NuGetFallbackFolder is created and required by Net Core 2.x Sdk. And if you use Net Core 3.x sdk, it does not need that folder and is not a problem any more. Since I did not know how you installed VS on the German PC, not sure whether you have the dual operating system on one PC, you should check your German system, and make sure if the folder path of Fallbackfolder exists.
If not, please install Net Core 2.2 sdk on your German system, and it would install the folder NuGetFallbackFolder.
And it this does not help, please try the following steps to troubleshoot the issue on the German system:
Close VS, open Control Panel-->Programs-->right-click on any net core sdk program-->Change--> Repair
add this node in your xxx.csproj of your Wpf Core project.
<PropertyGroup>
<DisableImplicitNuGetFallbackFolder>true</DisableImplicitNuGetFallbackFolder>
</PropertyGroup>
try to repair vs on German system

how to install GDAL into visual studio for c# on windows?

I'm gonna use GDAL into visual studio for c# on windows.
And followed some steps through some posts.
However, it seems it doesn't work between steps and, the biggest problem is that it can't build and install.
I will explain how to install, then if any of you knows and let me know why i can't install it, it will be so helpful.
to download:
Stable Releases, GDAL2.1.2 and MapServer 7.0.2, MSVC 2013/x64(mine:64), gdal-201-1800-x64-core.msi.
link: http://www.gisinternals.com/query.html?content=filelist&file=release-1800-x64-gdal-2-1-2-mapserver-7-0-2.zip
to set up paths:
System -> Advanced system settings -> System Properties -> Environment Variables =>
Edit System Variable: Path, C:\Program Files\GDAL\csharp
Add System Variable: GDAL, C:\Program Files\GDAL
(i also add two more: C:\Program Files\GDAL\gdalplugins, C:\Program Files\GDAL\gdal-data with names)
I downloaded a sample to test this environment setting.
(http://svn.osgeo.org/gdal/trunk/gdal/swig/csharp/apps/GDALInfo.cs)
(visual studio 2013)Add four of the dll-files(gdal_csharp.dll, gdalconst_csharp.dll, ogr_csharp.dll and osr_csharp.) to my project references from C:\Program Files\GDAL\csharp(there was no gdalconst_cshap.dell though, i download it from a site i found).
Change Platform target to x64 in Properties.
Run the program.
1) nothing happened.
2) in the case, i forced to change the running goes to Gdal.AllRegister() to chech if GADL and VS are linked though, it said "The type initializer for 'OSGeo.GDAL.GdalPINVOKE' threw an exception."
// I know there must be something i missed during process, but i think for now i can't find anymore. any help or hints or suggestion will be very welcomed!

XSockets throwing InvalidOperationException on GetExport<IXSocketServerContainer>

I'm running into a weird issue. I have exactly the same code. On one machine, it works flawlessly. On the other, It throws a InvalidOperationException on GetExport<IXSocketServerContainer>
The offending line is:
_serverContainer = Composable.GetExport<IXSocketServerContainer>();
Here's a screenshot of the exception as well: screenshot.
Any ideas?
The only difference I can think about are that one machine is Win 8, and the other is Win 7.
Further details: took the solution that worked (win 8), copied as is to other machine (win 7), clean all packages, reinstall all nuget dependencies, went over all project adding or reimporting the dependencies, still now working (on the win 7 machine), though the project will build without errors.
Took that non working (yet compiling) project back to the first machine, and it won't work on that machine either. Utterly out of ideas.
Ok, Seems this was off the bat ...
It has nothing to do directly with XSockets.
What happens is a (known?) difficulty (read: bug) in VS.
Project A (.exe) includes project B (.dll).
Project B has dependencies that will be copied to it's output directory.
Project A will not get the dependencies that project B needs, and will burn and crash at runtime.
Solution:
Create a Post build event for the project (project properties -> Build Events) that looks like
copy /y source target
You probably want to have double quotes around your source and target, to avoid failing if they contain spaces.
You want the /y to overwrite files in the target.
You might need to play a bit in order to get the right syntax as well:
copy /y "$(ProjectDir)..\project_b\$(OutDir)some_mask.dll" "$(ProjectDir)$(OutDir)"
Related links:
Visual Studio Post Build Event - Copy to Relative Directory Location
Copy file(s) from one project to another using post build event...VS2010
Copy bin files on to Physical file location on Post Build event in VS2010
VS BUG:
https://connect.microsoft.com/VisualStudio/feedback/details/694561/copy-local-private-true-private-on-a-project-reference-needs-to-also-copy-what-the-target-project-marks-as-copy-local
Addendum:
It seems that in addition to the above, if you run XSockets from a folder that has # (sharp, or hash character) in it's path ... the server is going to throw the above exception as well.
The reason for this is that we use the following method to locate the assemblies.
public static string GetAssemblyDirectory()
{
return HostingEnvironment.IsHosted
? HttpRuntime.BinDirectory
: Path.GetDirectoryName(new Uri(Assembly.GetExecutingAssembly().CodeBase).LocalPath);
}
So, since we use:
new Uri(...)
the "#" will be removed and the path will not find the assemblies, and then you will get the "Sequence contains no matching elements..." exception.
However, it should work if you add the path manually before using the plugin framework... Something like.
Composable.AddLocation(Path.GetDirectoryName(Assembly.GetExecutingAssembly().Location));
You can ofcourse add any location, this "sample" would load all assemblies/exe in the bin folder of the executing assembly/exe
In 4.0 we will use the way described above and skip the "new Uri(..)" stuff.
Let me know if you have any issues.

File or Assembly Cannot be Loaded Error

I am working on a Setup program which creates a .msi file. There is a CustomAction program associated with it which is written in C#. There are three COM object references made in this CustomAction program which are necessary in order for it to work. They are as follows.
Active DS IIS Namespace Provide (C:\Windows\System32\inetsrv\adsiis.dll)
Windows Script Host Object Model (C:\Windows\System32\wshom.ocx)
NetFwTypeLib (C:\Windows\System32\FirewallAPI.dll)
As added information, following are the tasks I use these DLLs in my program for.
To set MIME settings for a particular file type.
To create a desktop shortcut to a folder.
To register a program as a firewall exception
.
Now, here is my problem. When I rebuild the C# program and execute the CustomAction program from within Visual Studio, it works fine and I can get the above three tasks done like a charm. However, when I actually build the .msi and try to execute it and install the program on my system, it gives an error. I'm using a Japanese OS so it gives the error in Japanese so I'll try to translate the error message in to English as best as I can. The error is something like this:
*
File or assembly 'Interop.IISOle,
Version = 1.0.0.0, Culture = neutral,
PublicKeyToken = null', or one of its
dependencies could not be loaded.
Cannot find the file specified.
*
This particular error message is given because it relates to the first dll (adsiis.dll) because it is the one which contains the IISOle namespace. Similarly it gives error messages relates to all the three COM objects which I made references to from my program. Now what I can understand from this is, somehow when this code is inside the .msi file it cannot find the appropriate COM objects. I'm really confused why this happens as the Setup gives the same error when I try to install the program even on the same machine which I used to code the CustomAction. Funnily it executes flawlessly from withing Visual Studio Interface. Please do help me with this. Thanks in advance!
Note that I'm working on Windows Vista Business, but I need my Setup to be able to install on a variety of Windows OS ranging from Windows Server 2003 to Windows 7.
Just encountered this today. Go to "Turn Windows features on or off" and scope out everything under IIS, including the IIS 6 stuff.
Make sure that the feature "IIS Metabase and IIS 6 configuration compatibility" is checked, found under "Internet Information Services" > "Web Management Tools" > "IIS 6 Management Compatibility".
Anton, finally I found out what was wrong.
When I reference, for instance, dsiis.dll then Visual Studio places an Interop module, namely Interop.IISOle.dll inside the bin directory of my CustomAction program. Which is where the CustomAction.exe can also be found. It does the same process when I reference the other two COM objects; wshom.ocx and FirewallAPI.dll. But my actual setup program which is written using Wix copies this CustomAction.exe to some other directory and the .msi uses that particular CustomAction.exe file. The problem occurs since Interop.IISOle.dll (and the others as well) cannot be found there. (The error message said what I needed to look for from the beginning it seems; I was foolish not to look for it but thinking there might be bigger problems)
So this is what I did. I instructed the Wix project to copy those Interop DLL files to the same place where the CustomAction.exe which is used by the installer resides. That solved the problem so easily.
I'm totally a newbie when it comes to Wix, plus we needs to use the CustomAction for 2 and 3 because of some reasons.

Categories