Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
    jammy is not listed
    Andres G. Aragoneses
    @knocte
    eoli3n: monodevelop is deprecated; the successor is dotdevelop
    Nikolay Mishev
    @NikolayMishev
    Hi guys me again.
    After I update VS for Mac 2022 to latest version I begun getting this error whenever I tried to build my extension.
    "Could not find a global instance of Visual Studio for Mac or MonoDevelop. Try providing an explicit value with MDBinDir"
    Any thoughts?
    I have VS for Mac 2019, VS for Mac 2022 and VS for Mac 2022 Preview installed if that helps.
    Dominique Louis
    @CartBlanche
    @NikolayMishev if you are loading your extension in VS2022 make sure its building using dotnet and not msbuild. Right click the project solution and there should be an option to uncheck in there under Build->General.
    Nikolay Mishev
    @NikolayMishev
    Thank you for this but it does not seems to fix the issue.
    ShalokShalom
    @ShalokShalom
    @knocte why not renaming the repo, then?
    Does anybody in the team care about fsharp?
    Andres G. Aragoneses
    @knocte
    @ShalokShalom because the maintainers of dotdevelop are not the same as the maintainers of monodevelop
    @ShalokShalom good question, I'm an F# dev myself too
    Nikolay Mishev
    @NikolayMishev

    Hi guys,

    Previously we were trying to migrate our VS for Mac extensions to VS for Mac 2022 so we kinda succseeded by following the steps from this wiki https://github.com/mhutch/MonoDevelop.AddinMaker/wiki/Migrating-AddInMaker-projects-to-support-Visual-Studio-2022-for-Mac-v17.x But one of our extensions uses gtk-sharp to show some custom dialogs within Visual Studio and this functionality is failing runtime after the migration with this error (System.TypeInitializationException: "The type initializer for 'Gtk.DialogAttribute' threw an exception." ---> System.DllNotFoundException: "Unable to load shared library 'libgtk-win32-2.0-0.dll' or one of its dependencies). This is working within VS for Mac 2019.
    Any help on this would be greatly appreciated.

    Matt Ward
    @mrward
    @NikolayMishev VS Mac does not support gtk#. You would need to port the UI to use native macOS appkit. VS Mac itself targets net6.0-macos and needs the macos dotnet workload installed to do the UI. I do not use the VS Mac sdk/extensions so not tried doing custom UI with it - in theory installing the macos workload and having your project target net6.0-macos should be enough. With my extensions I directly reference the dlls from the installed VS Mac, including the Microsoft.macOS.dll, so I can avoid anything to do with workloads - mrward/monodevelop-nuget-extensions@17e3e42
    Nikolay Mishev
    @NikolayMishev
    @mrward Thank you a lot.
    Nikolay Mishev
    @NikolayMishev

    Hello again @mrward another question I have regarding Visual Studio for Mac 2022. So we have custom project templates that we install in VIsual Studio and they work fine and all excep the part when we try to open specific project template through a command in the menu in that case we it seems that the method we use to open the specific template fails and fallbacks to the latest used template. This is the line we use(that by the way was working fine in VS for Mac 2019): IdeApp.ProjectOperations.NewSolution("TemplateID", false);

    The templates are visible in the VS new project wizard and are working correctly. So the issue should be just with line above.
    So is there something that is changed in VS for Mac 2022 and is there a place we can track such changes to the extensibility model of VS for Mac.

    Thank you in advance.

    Matt Ward
    @mrward
    Not really sure. If they are working in the New Project dialog then using ProjectOperations should work. This is with custom .nupkg files and the template id is unique?
    Will have to see if I can repro.
    Matt Ward
    @mrward
    Yeah something is not right here.
    Unless I am using the wrong template id :)
    Matt Ward
    @mrward
    Yeah it is broke. The port to native UI changed the behaviour. When the NSTableViews are loaded it gets a selection changed event which sets the selected template back to the first one in the recently used list.
    Nikolay Mishev
    @NikolayMishev
    Thank you @mrward so is there some place where we can folow the progress and see when this is resolved?
    Matt Ward
    @mrward
    I have an internal bug for this and a fix which should go into VS Mac 17.5. I suspect this will not be backported though and there is no real workaround here.
    Nikolay Mishev
    @NikolayMishev
    Thanks @mrward looking forward to the 17.5 release then :)
    Nikolay Mishev
    @NikolayMishev
    Hey @mrward quick question do you have some approximate date for the 17.5 release?
    Matt Ward
    @mrward
    @NikolayMishev Visual Studio for Mac 17.5 preview 1 is out now, as of a few minutes ago. That should include a fix for the new project dialog.
    Ghost
    @ghost~60bd9cee6da03739847e4eaf
    I'm new here, trying to install on windows. Encountered numerous problems. I start wi the first one:
    on https://www.monodevelop.com/download/
    "Download Gtk# on monoproject.com", click and get:
    ResourceNotFoundThe specified resource does not exist. RequestId:a84b55e5-601e-0043-2da0-f7a10d000000 Time:2022-11-13T20:42:01.2245635Z
    I'll post the others, but I took the immediate fact of encounter this error as a bad sign of what was to come
    Lex Li
    @lextm
    @Dan-Essin No one is now working on MonoDevelop for Windows. Please switch to other alternatives such as VS Code or JetBrains Fleet
    Ghost
    @ghost~60bd9cee6da03739847e4eaf
    What platforms are being worked on? How does one do "cross-platform development" if windows is not one of the platforms?
    Lex Li
    @lextm
    Ghost
    @ghost~60bd9cee6da03739847e4eaf
    Thanks. There is a Mono doc called Application Portability. It has a section labelled "Using Windows.Forms as a cross-platform API" that has no content. Is this because there are no significant issues using WinForms?
    Lex Li
    @lextm
    @Dan-Essin Mono as a whole is also going away, https://halfblood.pro/the-end-of-mono/ So, spare yourself from documentation that wasn't updated for a very long time. .NET Core is the unified platform for the future.
    Mr. Cookie
    @MrCookie0
    I know that monodevelop is ended, but can you tell me how to compile it?
    Lex Li
    @lextm
    @MrCookie0 In its last few months of life, the repo was not compilable. So, don't waste your time on mono/monodevelop repo unless you are really a C#/MSBuild guru that can help yourself. If your goal is to somehow compile it on Linux alone, dotdevelop/dotdevelop is getting closer to a full feature release, https://github.com/dotdevelop/dotdevelop
    Mr. Cookie
    @MrCookie0
    Thanks, @lextm !
    Ghost
    @ghost~60bd9cee6da03739847e4eaf
    It's the same ole story. A lot of people work very hard for a while to create things but then get distracted, co-pted or marginalized by some new, hot tech. There are so many unfinished, partially working projects. They are great for guru-grade folks. For mass adoption, and I presume that that is still a linux goal, the software is going to have to be much more reliable. It shouldn't require a PhD and 10 years experience to upgrade an OS version or install an app.
    Mono may be dead but the MS .NET stuff is still flaky and cross-platform compatibility still seems to be a pipe dream.
    AraHaan
    @AraHaan
    Agreed, cross platform compatibility even for things like System.Drawing.Common in recent versions went down the toilet when they started making it throw PNSE on non-windows systems on everything.
    Lex Li
    @lextm
    @AraHaan please be fair. System.Drawing.Common (on GDI+ or libgdiplus) is rather old and with badly maintained native bits. There are so many alternatives and many of them are much better. If you just want your decade old legacy code to be unchanged, that's a different story.
    @Dan-Essin I found it difficult to understand what you are complaining on with "It shouldn't require a PhD and 10 years experience to upgrade an OS version or install an app". Open source just works that way, you like it or not. "the MS .NET stuff is still flaky and cross-platform compatibility still seems to be a pipe dream" isn't unique of .NET. Take a look at all the cross platform technologies and they all suffer in certain ways.
    AraHaan
    @AraHaan

    @AraHaan please be fair. System.Drawing.Common (on GDI+ or libgdiplus) is rather old and with badly maintained native bits. There are so many alternatives and many of them are much better. If you just want your decade old legacy code to be unchanged, that's a different story.

    Which becomes a problem when you say, depend on things that the azure sdk depends on which then pulls in System.Drawing.Common because a few other dependencies uses apis that are no-opt and that specific code is practically unused in those dependencies as well (for example System.Configuration.ConfigurationManager, and/or System.Diagnostics.PerformanceCounter). But you do not depend on System.Drawing.Common directly though.

    And by things that can be unused are things like CAS apis for example.

    Nikola Nenov
    @nikolavn
    Hello, we are developing a VS for Mac extension that we built with the latest version of VS for Mac, however, we'd like to support older versions too. So far we have used the MDCoreVersionOverride property where we defined the lowest version we want to support, but it doesn't seem to work anymore as now the extension works only with the VS for Mac version it was built with. Is there another way to achieve that? We'd ultimately want to build with the latest VS for Mac version and support 17.3 and upwards. Thanks.
    Matt Ward
    @mrward
    Not sure what MDCoreVersionOverride is - I do not see that in the monodevelop code base. Are you using the VS Mac addin maker? You can specify which VS Mac version an extension supports via assembly attributes or in the .addin.xml file. However, an addin maker projects generates the supported version based on the VS Mac instance being compiled with. Also note that right now VS Mac has breaking API changes so the extension will likely need to be built against a recent VS Mac version for it to be available in later versions.
    The Microsoft.VisualStudioMac.Sdk seems to use TargetIdeVersion instead of MDCoreVersionOverride so try that instead?