Develop Reference

.NET custom dependencies (no nuget)

So, I'm having trouble adding a git project to my net Core solution, and after spending hours trying to figure this out and being uncapable of finding a solution online, I decided to ask here.
I have a forked github repo (link) in which I modified some files to suit my needs, but I simply can't seem to get it to work with my current project.
The problem I'm having is that normally, when I want a package for a .NET project, I usually simply go to nuget and fetch the necessary dependencies. This is usually very simple and straight forward. But now that I have these modified files, I'm unsure on how to proceed.
I have tried adding it as a submodule, but after I built the project, I got an exception saying that the dll could not be found.
Then I've tried adding the dll itself as a reference, but the ImGui.dll depends on a C dll which couldn't be found then (nor added to the project).
Finally, I've tried adding the csproj as a project of my solution, but that didn't work either
Do you know what am I doing wrong here? Am I missing a key piece or is it just something obvious I'm not seeing? It can't be this hard to get it to work

From the look of it, that repository produces a DLL (output type Class Library). So modify it to your liking, and use the sample program build (ImGui.NET.SampleProgram) to test your changes. Once you're happy, build the DLL project (ImGui.NET) and use the resulting DLL as a Reference in your own app.
In Visual Studio:
Solution Explorer>YourApp>References>Right Click>Add Reference...>Locate your DLL
This means you should also keep track of your modifications to the ImGui.NET project itself, since you may/will be required to maintain this in the future.
Hope this gets you started -- update your question with more specific issues once you're underway.
Edit:
Like #CoolBots mentions, I probably misread your question. Seems like the build depends on cimgui.dll, which you can hotlink from the ImGui repo along with your custom DLL. In fact, the demo app is using cimgui.dll, cimgui.dylib and cimgui.so. Regardless of linking method, you want the files to copy into your build folder. I don't believe subfolder /bin is necessary.
You can find all the cimgui dependencies for various operating systems in the ~/ImGui.NET/deps/cimgui folder.
The demo also utilizes NuGet packages Velrid and Velrid.StartupUtilities.
Depending on your own codebase, you may or may not require these NuGet packages along with the aforementioned class library.

Two projects with same dll, Cast issue

Hi fellow programmers,
I'm creating a ControlLibrary for future project's that uses the amazing MaterialDesignXaml library. In this ControlLib I use the MaterialDesignThemes.dll that contains several styled controls, resources and classes.
Now my problem is that I need to use the same dll's in the real application (sae sollution for now). If I want to use the mentioned control library in this project (as project reference) I always get this error:
Dll Error in Application Project
.
I understand the problem the compiler has with this, since It cannot check if two refrences (from seperate projects in the sollution) are the same dll. But how can I fix this?
The strange thing is that the designer complains like in the screenshot, but the application runs just fine...
I'm using TortoiseSVN for Version Management, maybe this has to do something with it?
Any idea's?

How do I add a reference to an assembly that wasn't built with the Silverlight Runtime?

I am looking for a possible solution where I can add ShapeMap.dll as a reference,
but when I try to add the reference I get an error stating:
You can't add reference to ShapeMap.dll, as it was not build against the Silverlight runtime. Silverlight projects will only work with Silverlight Assemblies"
What do I do now?

While Silverlight code may look and smell like good old .NET-backed logic, the runtime for Silverlight is different from that supporting regular .NET applications.
It is useful to think of the Silverlight runtime as a subset of the .NET runtime: Silverlight is meant to run in a "sandbox" whereby many the unsafe features such as direct access to the file system are not allowed.
For this reason, one can only add Silverlight assemblies to a Silverlight project.
The error you're getting is therefore as said: the version of ShapeMap.dll you have wasn't build for Silverlight runtime.
There are two ways out of this situation:
find or build a Silverlight-backed version of the DLL
somehow refactor the Silverlight application so that it leverages the features of the DLL by way of WebServices (if that makes sense, for the name ShapeMap.dll indicates that this may deal with UI objects which are hard/impossible to deal with remotely)
To get a Silverlight-backed version of the DLL:
First choice: It may just be that you can get the binary of the Silverlight version of the assembly where you found the .NET version.
Second choice: it may be that you can get the the source code of the [.NET targeting] DLL.
If so you can try -and I stress "TRY"- to make a Silverlight assembly out of it. The problem may be that the source code uses .NET-only idioms/API calls and you'll then need to convert these; several just .NET-to-SL "gotchas" can easily be converted, others are absolute roadblocks (eg. direct access to the file system, registry etc.), although, it may be possible to merely comment-out the offending sections of the code, if, somehow the Silverlight was not going to use the underlying features of the DLL.
Now... for sake of full disclosure...
there are a few techniques which allow "fooling" Visual Studio so that .NET assembly be accepted within a SilverLight project. See for example "Reusing .NET assemblies in Silverlight". Beware, however, that while very insightful as to the nature of the .NET and Silverlight runtimes, and possibly useful in some cases, these techniques are undocumented and, more importantly, depending on the subset of .NET API used by the DLL, may merely allow to get over over the build-time blocking, to fall into various run-time errors (when/if the application makes calls into the DLL to methods which in turn invoke .NET-only methods of the runtime).

If you have access to the source files for that assembly (dll), create a new Silverlight Class Library project and add all the existing source files to your new project. Then attempt to build the project. Depending on the amount of dependencies you may succeed in building a silverlight compatible version of the assembly.
If you don't have the source code, then sorry you're out of luck.

Silverlight works in a "subset" of the .net framework, some stuff is organized differently and works not like a regular WPF application (like that everything needs to be async in order to keep the UI responsive). You can see it as a "protected" .net environment, and therefor you may not reference or use non-silverlight dll's.
Like the previous answer states, use the source code and copy paste it into a SL library project, compile, and use that.

compact framework design time support from external dll

I know this has been asked before, and also there are answers which solves the problem partially. I've some user controls which we use in our warehouse mobile application framework, and to get design-time support I use DesktopCompatible custom arrtibute in DesignTimeAttibutes.xmta file.
This solves the problem if both the library and the UI project is in the same solution. For example I have this solution layout :
Company.Mobile (Solution)
Company.Mobile.Library (Project) this has DesignTimeAttributes.xmta
Company.Mobile.Project1 (Project)
Company.Mobile.Project2 (Solution)
Company.Mobile.Project2 (Project)
So when I reference Company.Mobile.Library from Company.Mobile.Project1 I have design-time support for the controls, but not from Company.Mobile.Project2. I also tried to copy xmta file to Project2 but still doesn't work.
Any ideas?
Thanks.

Besides having your library dll, you should also have an extra dll called yourlibrarydll.asmmeta.dll. Try coping this dll into the output folder of your Project2.

Create Project Dependency and Add Reference to Project still causes "The type or namespace name could not be found"

I have a solution in Visual Studio 2010 containing 6 projects (1 web application, 4 c# class libraries, 1 c# console application).
The console application is my test harness and use this to test external web services, output from methods from within my other libraries and general experimentation. This test console application has only one dependency on another project dependency, one of the C# libraries.
The referenced C# library is pretty simple:
namespace GowallaAPI
{
public class Gowalla
{
private static readonly ILog log = LogManager.GetLogger(typeof(Gowalla));
public SpotsInRadius GetGowallaSpotsInRadius(decimal lat, decimal lon, int radius) {
//snip
}
//other methods removed for brevity//
}
}
I have added to my console application a project reference:
And I've also right-clicked on References and selected Add Reference...
Then, I've gone to my console application and added;
using Gowalla;
Then hit build. I get this:
The type or namespace name 'Gowalla'
could not be found (are you missing a
using directive or an assembly
reference?)
I am completely baffled. I have:
Remove the dependencies completely (and then rebuilt with Gowalla references removed), and added them again.
I have removed the dependencies completely (like #1) and then added them as assemblies only (Add Reference...).
Checked that the target framework for both console application and class library is .NET 4.0 - they are.
Checked that all necessary items within the Gowalla class library are marked as Compile in the Build property.
Jiggled the build order of the project so that I am at least building the console application AFTER the library is built.
Done some shouting and swearing.
Given up and then returned.
Moved the Gowalla C# library out to its own project entirely and then referenced the assembly (like in 2).
Playing the having a constructor in Gowalla and not:
public Gowalla()
{
}
... and nothing has worked!
Can anyone see something obvious? Am I being utterly stupid? I have been on this for hours and I wonder quietly if this is a classic 'wood for the trees' moment...
Help appreciated.
EDIT 1: This is the Gowalla.dll exposed from Reflector:
ANSWER: After #gov's helpful suggestion to remove the GowallaAPI library and try and add something else I did that and started adding in the old code from the GowallaAPI library. Everything worked until I added:
private static readonly ILog log = LogManager.GetLogger(typeof(Gowalla));
log4net for some utterly bizarre reason kept throwing the build. Alas, after removing the line (the reference to log4net remains), the project built and worked perfectly thereafter. Thank you to #gov for setting me on the right path! :D

I had the exact same problem with log4net and it was resolved after changing target framework of the hosting project from ".NET Framework 4.0 Client Profile" to ".NET Framework 4.0"

I suggested him various things in the comments looks like one of them worked out.
#dooburt just forget about GowallaAPI and create a separate project like i say , sample.common and have a public class called utilities or so add that project here , just check a new project of type library and see whats the problem

Take a look at the .csproj XML, see if there is anything odd about the reference, one of these:
<Reference Include="Gowalla" ... />
<ProjectReference Include=".\path to\Gowalla.csproj" ... />

Have a look at the target framework of your class library and the test harness. I was having this error when the class library was set to .Net Framework 4 and the test harness was .Net Framework 4 Client Profile.