With Rider EAP, References to Services Objects Fail - c#

Trying to work on a C# project https://github.com/cliftonm/FlowSharp on my Mac (El Capitan 10.11.6). Install Rider, install mono connect to project and everything seems fine, but the project won't build.
Lots of stuff defined in the Services directory are not found (show up broken in References). File names in error messages actually exist (.csproj files from the project's local git workspace) and are readable.
Must be something basic, but help seems hard to find. Are there better tools for me? What do I need to make these tools work. New to C# and mono, but not to software.

Related

Setup FFMpegCore in Visual Studio 2019

I am confused on the basics of using a library. I understand that there is a library called FFMpeg and a wrapper called FFMpegCore so we can use FFMpeg with C#, correct? I downloaded both FFMpeg and FFMpegCore and I have them in my project's folder. Although I didn't perceive any class named FFMpegOptions in either of the file's folders.
I am stuck on how to actually set it up so I can use it in my little project, I never downloaded someone's library before. Can somebody please walk me though the motions of connecting the three of them together?
So far I experimented with:
Add a reference to my project, but there doesn't seem to be any .dll, .tlb, .olb, .ocx or .exe files to add
Add an existing project to my solution. There is a project called FFMpegCore.csproj but adding it raises a missing SDK error. Weirdly enough, opening the same project as a standalone doesn't raise any issues which makes me thing the operation I am trying is inadequate.
I am sure this is a silly and easy setup to perform but I just don't know enough to find a solution.
First you must download and install ffmpeg on your machine, (to test that it is working correctly, open a CMD and execute "ffmpeg", it will return the installed version.
Second, create a new project, (I recommend .NETFramework) once your project is created, it is necessary to install the package from NuGet, this function is found in tools> NuGet Package Manager> Manage packages for solutions...>
Then search for FFmpegCore and install it in your project,
The necessary dependencies will be added, now you can start programming with this Framework,
I recommend the FFMpeg.cs class as an example of the documentation, to start with.
Good Luck.

Integrate Wix setup with application's debug folder

I have a .NET application debug folder but not the complete visual studio solution. I am trying to generate a wix installer from this.
Things tried:
I created a project called setup using WIX toolset.
In my .net solution, there are now two projects, the main project helloWorld and the wix project setup. Inside the setup I added the reference of helloWorld and it worked fine. I am able to create the installer for my helloWorld project.
Here, I added the reference of the application project for which we want to generate the installer.
Problem:
As I have only application's - debug folder(i.e the application's .exe , .exe.config and other files) and not the complete visual solution. I am not able to generate the WIX installer from it.
Question:
Is it possible to generate WIX installer from debug folder without having the complete visual studio solution?
If possible, are there any document or things I can try?
Redistributing Debug Binaries: Debug versions of binaries should not be redistributed for several reasons (technical, security, legal, practical, etc...).
Technically: First of all, they require their own complement of debug runtime DLLs in order to run and these debug files are not present on normal, non-developer computers with standard runtime components installed. Debug dlls often have an extra "d" in their file name: mfcm140d.dll versus mfcm140.dll for example (look for them on a PC with Visual Studio installed).
Legally: Redistributing debug binaries for standard runtime components is actually illegal - it violates EULAs with regards to what is redistributable (normally). And no, this is not a trifle - don't do it.
Security: Debug binaries also contain a lot of debugging symbols and in .NET assemblies a lot of meta information that should generally not be sent to others. You would have to ask someone else for the full technical details.
Practical: Several practical issues too. For one thing: don't underestimate the confusion involved in redistributing debug versions of files. Creating an internal setup with debug binaries to test on computers set up with debug runtimes could work for internal QA though. Just wait for someone to send that to a customer or for someone to upload it for download on your web-site (by mistake).
For debugging purposes some people redistribute *.pdb files - "Program DataBase" - along with their software - instead of debug dlls. More on PDB files.
Hello WiX: With the above stated, adding debug dlls to a setup is no different from adding release files. There is a WiX Visual Studio Hello World example here. It should show you the basics of compiling a working setup with WiX and Visual Studio. There are also a bunch of quick start tips for WiX here (many links to samples).
Some Links:
install VC++ Debug Runtime Distributable (debugging purposes ONLY)
MFC100d.dll Issue in VS2010

C#.net DLL COM wrapper and installation

I'm making a load of code bits that will eventually be used in another C# program long term, but I may want to use it in various other apps, and I need to use it easily now as it gradually develops. So I've written a few C#.net DLLs in Visual Studio Express 2017. Two of which reference a 3rd-party DLL (one of which was installed by other software, one of which I just pointed at in Visual Studio), and one of my DLLs references my other 2 DLLs. I've ticked the boxes to COM register my ones and I'm now happily using them from Excel/VBA.
But how do I install it on another Win10 machine in simple steps though, so I can use the same spreadsheets and automation on those computers? (preferably with some explanation of what the steps are actually doing?) I haven't had any luck with the other options I've googled, maybe they're not "idiot proof" enough for me, or my DLLs have dependencies on other DLLs, or I'm getting them from the wrong place.
I assume these are 64-bit DLLs (they're complied for 'Any CPU') so I
want to copy them into the 64-bit place (syswow64)? Or should they go
in system32 as well?
I guess I get them from my 'release', not 'debug' folders?
I also have .pdb and .tlb as well as .dll. Do I need these? Maybe they're the missing piece of the jigsaw?
What's the difference between regsvr and regasm and what should I be using? (Or both).
Also is there a simple way to make a DLL copying and COM registering installer app? And if yes, does that still apply if it's VS Express
2017?
Thanks for the help!

Sharing same rules for Stylecop and Fxcop across Build server and Developer Machine

We are trying to setup continuous integration process. As part of this we have setup Jenkins on build server . Plugins are added to Jenkins in order to check and validate StyleCop and Fxcop rules.
We are multiple teams working from different locations. As we are implementing Stylecop and Fxcop in Development process , We would like to share one single copy of Stylecop setting and Fxcop ruleset across developers and also we want to use the same rules in Jenkins plugins Build Machine .
Below I have added a image on what we are looking at . As below each developer will be directly accessing the settings file in Build Machine.It's Seems difficult ,but if there is a way surely we would like to implement the same.
We are using GIT, TFS , Jenkins and Visual Studio 2013 . Please let me know your comments on this
We store our StyleCop.Settings file in TFS at the team project root/solution root. So you might still have duplication across team projects but we mainly work out of two team projects at our company so it's not that big of a deal.
We also store the StyleCop binaries in TFS such that each developer doesn't need to install StyleCop and it also doesn't have to be installed on the build server that way. We'll include it in the csproj file like this
<Import Project="$(SolutionDir)\Tools\StyleCop\v4.7\StyleCop.targets" />
So our tfs structure might look like this:
TeamProject/
----Dev/
----Main/
--------Solution1.sln
--------Solution2.sln
--------StyleCop.settings
--------Tools/
------------StyleCop/
----Release/

LibGit2Sharp fails to find git2.dll

I have built a tiny wpf app that manages a website I am working on. The key feature of this app is that it allows me to checkout different branches of a theme repository. This works perfectly in visual studio, but when I publish, install and run the app on my windows 8 machine it comes back with:
{"Unable to load DLL 'git2': The specified module could not be found. (Exception from HRESULT: 0x8007007E)"}
I have searched through the internet and stackoverflow. There are similar questions, such as Unable to load DLL 'git2.dll' The specified module could not be found but the answers provided (as well as the answers shown in the github issue described in the answer) bring up another error:
Unable to find an entry point git_reference_oid in git2.dll
I have tried installing the latest through nuget, including a compiled dll and adding the git2.dll, including the libgit2sharp project in my solution. Once again, it works perfectly when I run it all through visual studio, but fails when I publish, install and run it.
I was unsure what information needed to be included so please feel free to comment and let me know so I can update the question.
Thank you!
The computer you're running the installed executable on may lack MSVCR100.DLL or MSVCR110.DLL (depending if git2.dll has been compiled using Visual Studio 2010 or 2012).
A fix has been recently merged in libgit2 which removes the need for this dependency.
Indeed, running dumpbin /IMPORTS git2.dll against those binaries doesn't show any dependency against MSVCR1x0.dll any longer.
The latest tip of the vNext branch of the LibGit2Sharp project embeds those updated git2.dlls. It's recommended to compile the project (using the build.libgit2sharp.cmd tool and use this version (manged assembly + native binaries) instead).

Categories