First of all, thanks for the help in advance, and excuse me for my relative lack of knowledge on these subjects, and this long post. I have a strange reference issue I'm trying to work out. I've done many hours of research on this subject, but I think my limited knowledge is holding me back from understanding. I'm losing my mind a bit here.
We are reviewing a project and came across an odd situation where there are references to System.IO and System.Runtime in the original .csproj file for an application (Sitefinity 10.1.6502), but in the copy of the .csproj we have on file post-development they have been removed. There are still references to System.Runtime.Caching and System.Runtime.Serialization in both.
When I looked online and in Sitefinity's public Git example repos, I found that about 1/2 of the examples with code for the same version DO have and like the original file does, and 1/2 DO NOT have them like the file in our repo. Some appear to have those references added at a later time when upgraded versions (to 10.2 or 11).
I also do not see System.Runtime.dll in the current /bin folder, or see it mentioned in web.config. I do not have access to the GAC.
The question is whether these missing references will cause any problems. The project seems to compile properly in VS2017 using the post-development .csproj file we have (without System.IO and System.Runtime)
We believe the project was originally built in VS2015, and found this article that mentions the exact references we're dealing with, so perhaps VS2015 was part of the problem? Unresolved Project References for System.IO, System.Runtime
I understand these are facades and that System.IO is a namespace in System, which is directly references in both .csproj versions, so that should be covered, correct?
The real question is whether the missing in the post-dev .csproj file could cause any issues. Like I mentioned above, the project is compiling without it in VS2017, and the files seem to work fine on a testing server (can navigate the front-end web pages and all functionality works, but we have not been able to test any of the back-end functionality due to it sharing a database with the live environment (out of our control).
Through my research I've seen it mentioned that System.Runtime should get automatically included during tooling/compiling, and that in normal circumstances it does not need to be directly referenced like it is in half the repos we saw. Is this correct?
I worry less about System.IO because it is already included via System, but from what I understand that isn't the case with System.Runtime
Again, thanks so much for helping clear this up for us, we're beginning to go batty trying to figure out if this is an issue we should worry about or not!
Related
I have a large solution, containing several projects, all with different dependencies and Nuget packages.
For one specific project, when running, I eventually get an exception "Could not load file or assembly 'System.Threading.Tasks.Extensions, Version=4.2.0.0, [...]"
This happens when referencing one of our types for the first time, which doesn't have an obvious dependency on this specific assembly, but it is part of a large project that probably has one.
The thing is, We do have System.Threading.Tasks.Extensions in the bin folder, it just appears to be a different version than the one that is expected by this code.
I have tried to consolidate versions and update this package and dependent ones, to no avail.
What I am looking for specifically, is how to figure out what project/file/etc is expecting the specific version, and why.
As far as I can tell, everything in the entire solution appears to expect the correct version, yet something obviously doesn't.
The answer may be a Visual Studio option, an external tool (I have access to Resharper and other Jetbrains software), or a Nuget tool that I am not aware of. Anything that allows me to pinpoint what or who is expecting this erroneous version, so that I can then fix it, will qualify as a valid answer.
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.
I found tons of posts asking about how to fix when Microsoft.SqlServer.Types.dll is missing, but I have the exact opposite issue -- it is in my output directory and I have no idea why.
The project in question references another global project within the solution, but I have checked the references and extensions for both projects -- nothing about Microsoft.SqlServer.Types. So, any idea as to why it would be considered a dependency when I rebuild the solution? I go to "Add Reference...", Extensions, and I can see "Microsoft.SqlServer.Types" in the list, NOT checked. How do I get rid of this reference?
Background: I just added reporting to my project and was using a data source (.xsd file) in my project. I have since switched to using simple class/object references as the data source so I deleted the XSD data source that used OLEDB to Foxpro DBF files. But I am thinking the Microsoft.SqlServer.Types reference got added at that time and now it won't go away.
The DLL (and regional folders for it) copy to my output directory because I am using the trick where all referenced DLLs get copied and then embedded into the application executable (so that I don't need to use ILMerge or deploy a bunch of DLLs -- the exe is standalone in that regard).
How do I find out where this reference is still sticking and get rid of it?
Never mind, it looks like Microsoft.SqlServer.Types is required by Microsoft.ReportViewer.Common. So, just adding reporting to my app brings in a lot of stuff... (well, not really that much, size-wise...)
When I run unit testing to serialize to an xml file, I keep getting error message:
Could not load file or assembly
'Company.Fin.Bank.Common.XmlSerializers.dll, Version=1.0.0.0,
Culture=neutral, PublicKeyToken=null' or one of its dependencies. The
system cannot find the file specified.
I guess Company.Fin.Bank.Common.XmlSerializers.dll may be in cache somewhere but it is impossible to find this dll, even though i don't need that dll. I want to remove it. But where can i find it? is it possibly in a cache? if yes how can i clean the cache from VS? This problem is very new to me.
What a weird part is that i used another laptop (win 7) to run the unit testing, there is no error message i got - it worked. but when i used my own laptop (win 8) i keep getting error message. I have no idea why.
I hope to find solution from you. Your help means alot. Thanks!!!
That assembly is dynamically generated by the framework (XMLSerializer)
In .Net implementation, the XmlSerializer generates a temporary
assembly for serializing/deserializing your classes (for performance
reasons).
Also, this may be normal behavior - is it stopping your application from running?
even though i don't need that dll
Visual Studio will usually remove unneeded DLLs. Typically this is caused by dependencies (which are harder to keep track of).
I want to remove it.
Check in the References of the project in the Solution Explorer. If any of them have a yellow triangle that means they can't be found (the project may still compile and run if you aren't actually using that reference).
is it possibly in a cache?
As Daniel Kelley mentioned C:\Windows\assembly and C:\Windows\Microsoft.NET\assembly are where the global assembly cache is located. If it isn't there check the Hint Path of the reference (it will show up in Properties).
Good luck finding your reference, keep in mind that you need not only the actual DLL but all of its used references in most cases. Also a decompiler like DotPeek can be useful if you need a more discreet way of looking at references.
I'm attempting to follow David Betz' wonderful advice on how to use a library project in both your .NET and Silverlight code. In particular, I'm using his File-Level technique: I have a .NET library project already set up, so I created a Silverlight project, and added links in the latter to the former's files.
Unfortunately, there is a problem. I get compilation errors like crazy, of the form:
The type '...' exists in both 'Util.dll' and 'Util (Silverlight).dll'
In all of my other projects, I only reference one or the other. Neither Util dll has a reference to the other, so I'm not sure why the compiler can see both DLLs from any of the other projects.
Any ideas?
Answer posted by frank in comments. Porting to answer and community wikiing it in hopes that it'll be accepted as the answer.
Comment
Argh! It really was this simple :) I just fixed the compilation issues other then this one, and it suddenly stopped complaining.
I also added to the linked projects Project Dependencies on the real projects, and that helped keep the errors more consistent, at least.
– frank