since I'm trying to get gstreamer-sharp 0.99 to run with my application, I heard, that gtk-3 is needed for gstreamer. Has anybody tried to build gtk-sharp 3.0 for monodevelop? I'm running fedora and tried, but all I could do, is link the dll manually to my project and the application didn't start. Is gtk-sharp still beta?
Thanks for your help.
Currently is possible to use gtk-sharp3 in MonoDevelop (at least in Linux). In Linux Mint 17 Quiana is necessary to install gtk-sharp3 package (no need to build) and add (in extension manager, install from file button) to MonoDevelop MonoDevelop GTK#3 Project Template extension.
This requires a MonoDevelop version >= 5 (see extension addin.xml file) - based on Xamarin packages (again, in my system). Installation guide for debian based systems.
GUI must be edited in an external program, Glade (a glade package) - see Gtk#3 project template descriprion.
Maybe required step is use the latest Mono release (see this) and probably required step is install Gtk3 first (libgtk-3-dev package and his dependencies). I have installed Gtk2 and Gtk3 as well as gtk-sharp2 and gtk-sharp3 simultaneously.
After creating GTK#3.0 project using template is (for my) necessarily add reference to gio-sharp v3.0 and regenerate MainWindow.ui with the use glade!
I hope that's all!
since I'm trying to get gstreamer-sharp 0.99 to run with my application, I heard, that gtk-3 is needed for gstreamer.
gstreamer-sharp 0.99 doesn't depend on gtk-sharp 3, it depends on glib-sharp 3, which, as of today, is hosted in the same repo as gtk-sharp 3, but that will change soonish.
Has anybody tried to build gtk-sharp 3.0 for monodevelop?
MonoDevelop only works with gtk+ 2.x versions. If you install gtk-sharp 3, you will not break or override gtk-sharp 2.x, as they can be installed in parallel.
I'm running fedora and tried, but all I could do, is link the dll manually to my project and the application didn't start.
Tried...? And what...? What happened? I'm assuming you failed? How did you fail, what error did you get?
Is gtk-sharp still beta?
gtk# 3 yes, gtk# 2.x is very mature though.
Related
I published my program(.net core 3.1 winform program). but it doesnt excuted even installed .net core 3.1 run-time package. so i install .net core 3.1 sdk package, it works.
why i install sdk instead of run-time package?
The software development kit (SDK) includes everything you need to build and run . NET Core applications, using command line tools and any editor (including Visual Studio). The runtime includes just the resources required to run existing
There was a problem creating a single file by using app.config in the wrong way.
When app.config was used in the correct way, it was confirmed that it works normally only with the runtime sdk.
Previously, both *.dll.config and *.dll were required, but after correcting it, only *.dll.config worked normally.
I have made a project in VS2019. I have the same project in .NET Core and .NET Framework. I use a COM reference in my project. I would like to migrate these projects to Pi4.
A simple Hello World project (.NET Core) is running successfully on the Pi4 machine. However, when I try to run my project (.NET core or .NET Framework) it does not run on the Pi4. It says COM is not supported.
I tried to build the project using MSBuild in my Windows environment after looking for solutions in Google. I also see a similar error here. The error is: error : MSB4803: The task "ResolveComReference" is not supported on the .NET Core version of MSBuild. Please use the .NET Framework version of MSBuild.
The .NET Framework project also gives a similar error.
error MSB4028: The "ResolveComReference" task's outputs could not be retrieved from the "ResolvedFiles" parameter. Object does not match target type.
Does anyone have similar issues?
https://github.com/microsoft/msbuild/issues/3986
According to the above link. The employee of Microsoft is saying they can not give solution in the near future.
Set the Projects to x86 for them to build the Interop, the Interop created still could not be used in x64 runtimes.
Add the COM Reference to the Core project, Build it and you will get an Interop.YourCom in the bin/x86/core/debug folder.
Remove the COM reference, and re-add the Interop, it will be put into the Assemblies Dependencies, and MSBuild will work.
My MSB4803 was from a WIXInstaller project, for ADOX, and Microsoft.Office.Interop.Access.Dao
I stumbled upon this question many times and I experienced the same several times in different projects. It doesn't matter if it is Visual Studio 2019 or 2022 and the version of the build, unless you are working with the old MSBuild in a legacy environment, the COM Reference doesn't work. It is always safe to build it in the command line to understand if anything in the VS environment works. I don't truly understand why Microsoft let you make those references in the Visual Studio environment when they will not work nearly anywhere else.
There are some workarounds that might or might not work but if your code is already pointing at a COM library there is no much to do. You can install the NuGet package which is going to pass the build stage and remove the COM reference.
Install-Package Microsoft.Office.Interop.Excel -Version 15.0.4795.1001
The NuGet package has some differences at the types level that you will need to fix (the COM reference allows you to get specific types instead of objects from the cells values)
In any case, you will need the COM installed in the server, there is no workaround that issue.
I wouldn't say I like this error message or the link it shows on how to fix it, to be polite.... ;-);
I figured it out and thought as there are a lot of answers that are not helpful to share mine. What I did is update your command to force the use of msbuild.
dotnet msbuild -v:normal "FullOrRelativePathTo\MyProject.csproj" -p:Configuration=RELEASE
If that fails, try:
"C:\Program Files\Microsoft Visual Studio\2022\Enterprise\MSBuild\Current\Bin\msbuild.exe" "PathTo\Project.csproj" /p:Configuration=RELEASE
I know I'm late to the party, but here is a workaround working for me when I want to use Office Interop in .NET (Core):
Create an empty .net Console app (I'm using Rider and .NET 7)
Build it with the default MSBuild (17.0 in my case at the time of writing)
Add Interop references to the project file (I don't use Nuget, only generate these in a dummy .NET Framework project while adding COM references to Office libraries), eg.
<ItemGroup>
<COMReference Include="Excel">
<Guid>{00020813-0000-0000-C000-000000000046}</Guid>
<VersionMajor>1</VersionMajor>
<VersionMinor>9</VersionMinor>
<Lcid>0</Lcid>
<WrapperTool>tlbimp</WrapperTool>
<Isolated>False</Isolated>
<EmbedInteropTypes>True</EmbedInteropTypes>
</COMReference>
</ItemGroup>
Change the solution MSBuild version to 4.0
Try to build the solution, but the project will not even load properly due to an outdated MSBuild version
Revert the MSBuild version to the default one
Build the project - success! (this is the magic part, I can't explain it :P)
I've been excited about Uno but at the end of the day, I'm a diehard Windows 10 M supporter and would like to publish an app for the platform before it's completely buried and impossible to target.
To get fun new controls in Windows 10 15063, I need WinUI 2.3, but I'd like to use Uno.UI alongside it.
If I use the guide for WinUI installation, my Windows build works just fine. The issue TwoPaneView with Uno Platform seemed promising but the only answer falsely asserts that not using a namespace with TwoPaneView will build on Windows 10 -- maybe with 1903 minimum but not with 15063 minimum in release mode.
How do I properly juggle the namespaces? I'm okay with splitting out a few per-project files if I have to but I would rather not.
Ahem... In point of fact, I didn't "falsely assert" anything!
WinUI and Uno.UI will build just find in a UWP head project targetting the Windows 10 Creators Update (Build 15063) however you can't use the ".NET Native tool chain" with such an old SDK.
You can check this by changing the min targetting version of my "TwoPainView" project (from here) and compiling (in debug or release without "Compile with .NET Native tool chain") which will result in no errors but a couple of (entirely sensible) warnings along the lines of:
Type 'Windows.UI.Xaml.Controls.TwoPaneView' is defined under contract 'Windows.Foundation.UniversalApiContract' version '8.0.0.0', but the contract version for the targeted min version is '4.0.0.0'!
And this is correct. It is unlikely you will be able to use the TwoPaneView on such an old SDK.
I am doing maintenance work on a VS2010 C# project built against .net v3.5.
I recently changed the project Target Framework properties to the latest version listed (v4) - due to an expectation of using a version of .net that is actually included in Win10 by default - and rebuilt without any apparent issues.
Unfortunately the embedded dependency in the generated .exe is still for .net v2.0.50727 (which is what is reported for v3.5 AFAIK) and the target machine (a clean install of Win10) is asking to install .net 3.5.
Using MS VS2010 v10.0.40219.1 SP1Rel.
Unfortunately upgrading the build tools isn't an option (building the program with VS2015 works just fine).
I have gone googling but don't seem to have found any similar reports.
Based on some of the comments already posted, I seem to have not made myself entirely clear - hopefully the following will help.
1) the intention/requirement is to be able to install this app on a clean install of Win10 without needing any further downloads. (installing .net 3.5 is easy to do, just not what is wanted)
2) the ultimate build environment for this is automated, visualized and not in my control and therefore upgrading the tool chain is a major pain that I'd like to avoid if possible.
3) AFAIK there are no third party libraries involved. All of the listed references (dll's) are v4.0.30319.
4) this is a XAML-based development, one part of three projects in the solution - the other entries are the installer and a C# custom installation library. As far as I can tell everything is set for .net v4.
Unfortunately the embedded dependency in the generated .exe is still for .net v2.0.50727 (which is what is reported for v3.5 AFAIK) and the target machine (a clean install of Win10) is asking to install .net 3.5
So there is some dependency in your project that targets that version of .NET. It could just be that you need to Build > Clean Solution and with a Build > Rebuild Solution the problem is solved.
Otherwise, assuming some library does require some .NET 3.x library, the installation request is entirely correct. Windows 10 does not have an option for installing .NET 2.0 and another for installing .NET 3.5. If you search for Turn Windows features on or off you will see this:
Any dependency on a .NET 2.x-3.x library will trigger the activation/installation of the first feature in the dialog.
As far as I can see, you have 2 options:
Move everything to a framework supported by Microsoft, most preferably .NET 4.7.2 given support and security.
Deal with the installation process and understand that Microsoft does not install these versions of .NET in purpose. You can, however, add these installers as a prerequisite and even bundle them with your installation, but that won't help much.
Thanks to all who have tried to help me!
The issue has been resolved.
There appear to have been two causes for this issue and my confusion:
it turns out that the blank install of Win10 that the testing was being performed on was not entirely clean - the pre-installed network drivers/utilities from intel also had a .Net v3.5 dependency...
one of the embedded resources in the project was effectively a uncompressed tar-ball containing a number of files; including an executable that had the dependency on .net v3.5 - this was a binary blob stored in svn so the content was had not been updated for several years (ie well before my involvement) ...
With both of these issues addressed it would appear that my problem is solved, so once again thank you for your feedback, suggestions and patience,
PeterT :->
Mono's C# REPL has on its page this bit of info:
A GUI version of this tool is called gsharp and is available when you install the mono-tools package
The same bit of info is mentioned in the Mono 2.2 release notes.
However, while I've installed the 30-day trial of mono-tools (vsix for VS2010), and the normal Mono for Windows package (2.10.8), I don't see anything in either that lets me open the window from the screen shot "C# InteractiveBase Shell". I also can't find any files on my disk (after installing both) starting with 'gsharp'
Did 'gsharp' move somewhere else?
I know the source is available as part of the mono-tools repo # https://github.com/mono/mono-tools/tree/master/gsharp, but just trying to find a 'release build' to use instead if possible. :)
Mono-tools for Visual Studio is a former product of Novell, which is discontinued (which Xamarin doesn't offer either).
I recommend you try to install Mono for Windows official bundle from http://www.mono-project.com/ If that installer doesn't include it, I recommend you compile mono-tools yourself, shouldn't be very hard with cygwin or mingw32.
PS: Note, "Mono tools for Visual Studio" and the "mono-tools" module (https://github.com/mono/mono-tools) are two different things.
(BTW, Mono 2.2 is very old. Only accept Mono 2.10.x or higher nowadays)