I need to get into FluentNhibernate and NHibernate code so i rebuild the solutions
and used the new assemblies, but the problem is that there is an assembly called
NHibernate.ByteCode.Castle.Dll which refuses to load the my own version of Nhibernate
and keep telling me that the Public Token doesn't match, so where can i get the source code
for this assembly, so i can reference my NHibernate assembly and rebuild it???
or may be the question is : is it open source ???
:$
how stupid I am !!!!
it comes with Nhibernate source code,but what made me confused is when I opened the Nhibernate Solution, the Nhibernate.ByteCode.Castle project wasn't there! !!!
but there is another solution file called NHibernate.Everything.sln, i opened it, and voila !!!
there it is in the solution.
Related
For example, I want to find the source code of IEnumerable, but it is not in
https://github.com/mono/mono/tree/master/mcs/class/System/System.Collections.Generic
So where is it?
I went to the GitHub repository and pressed T to activate the file finder and then typed in IEnumerable and one of the search results was:
https://github.com/mono/mono/blob/master/mcs/class/corlib/System.Collections.Generic/IEnumerable.cs
#MattWard already pointed out the key.
I just want to inform you that not all System.* classes are in System.dll, even for Microsoft .NET. If you go to MSDN you can see clearly that IEnumerable is defined in mscorlib.dll, which maps to "corlib" in Mono.
This tip applies to other classes as well.
I need to send mail from a Windows Embedded Compact 7 device and I'm trying to use OpenNETCF.Net.Mail.
My project is in VB.NET, CF3.5 and when I add OpenNETCF.Net.Mail to the project references the building fails (without adding a single line of code related to that library).
I have added also OpenNETCF, OpenNETCF.Net and OpenNETCF.Windows.Forms without any problem.
I get no error in the output log, just at the end the word FAILED...
I have never used OpenNETCF before so I apologize if my error is trivial but I couldn't find any solution.
To get this problem it is enough to create a new SmartDevice project (VB.NET, CF3.5) and in the property of the project to add a reference to OpenNETCF.Net.Mail.dll: the project doesn't compile any more.
I just get a warning about a version conflict:
Consider app.config remapping of assembly "System, Culture=neutral, PublicKeyToken=969db8053d3322ac, Retargetable=Yes" from Version "2.0.0.0" [] to Version "3.5.0.0" [C:\Program Files (x86)\Microsoft.NET\SDK\CompactFramework\v3.5\WindowsCE\System.dll] to solve conflict and get rid of warning.
C:\Windows\Microsoft.NET\Framework\v3.5\Microsoft.Common.targets : warning MSB3247: Found conflicts between different versions of the same dependent assembly.
Searching info about that warning I found that it is "safe" to ignore it because the OpenNETCF version that I'm using (2.3.12004.0) is compatible with CF3.5.
If I remove the reference to OpenNETCF.Net.Mail.dll and I add a reference to OpenNETCF.Windows.Forms.dll I get 5 warnings about remapping but the project compiles.
Anyone has a suggestion to solve my problem?
Thanks in advance.
Steve
Hi,
it seems that this topic is not very interesting but I've found the solution and I want to share it.
I contacted OpenNETCF support and Chris Tacke answered very kindly.
The solution is to remove from project references System.Xml.Linq that for some reason sometimes generates this kind of problem in VB.NET CF 3.5 projects.
I have found that adding an entry to the DbProviderFactories in LINQPad.exe.config does not make it show up in System.Data.Common.DbProviderFactories.GetFactoryClasses().Dump();
I had to add it to machine.config to be able to see it and use it. Is that to be expected?
Specifically I was trying to add the Oracle ODP managed entry since an assembly I reference requires it. I am told that the point of using the managed provider was to make the assembly more self contained and portable and so having to touch machine.config trashes that idea.
Try adding it to Linqpad.config. The Linqpad.exe.config file is for LINQPad itself whereas linqpad.config is for your queries.
I just got a new PC (Win 7) with VS 2010 (same version as my old PC). I got a VB.NET solution from source control that contains two projects. One of the projects builds fine. The other project flags every non-MS Imports statement with:
Namespace or type specified in the Imports &1 doesn't contain any public members or cannot be found. Make sure the namespace or the type is defined and contains at least one public member. Make sure the imported element name doesn't use any aliases.
The ironic thing is that the working project within the same solution references all the same DLL's. I've removed and re-added the DLL's so I know they're there, and I can expand them in Object Browser, so I know they contain public methods.
I've ran out of ideas of things to try. Can someone throw me a bone, plz?
I had the same problem which I fixed by changing the Project Properties->Compile->Advanced Compile Options->Target Framework value from .Net Framework 4.0 Client Profile to .Net Framework 4.0
I had this happen. For me, the new DLL was targeting Dot Net 4.5, while the project which referenced it was only targeting 4.0. Switching the new dll to match fixed the issue.
I've had a similar issue as this before. In my case the problem was that the dll's were located on a network share drive (which in my system showed as q:) so when I referenced them the file path was q:\folder structure\file.dll. Upon switching machines, my system no longer referenced that share drive as q:\ but by another drive letter, causing my program to error out similarly.
In my case, I was able to correct this issue and prevent it from happening again by changing the way I referenced the dll from the drive letter it was assigned by my local system to the network path (\SERVER NAME\Drive Letter\file path\file.dll).
I was experiencing the same issue. The DLL I was referencing was built in framework 3.5. The project I was referencing the DLL was being built in 2.0. I switched the referring project to 3.5 and it built perfectly.
I had this problem with projects which were referencing the same version of the framework. I solved it with the following steps.
Remove reference to DLL
Clean and ReBuild DLL
Clean and ReBuild Project
ReAdd Reference.
This happened to me in a Visual Studio 2019 VB project with System.Data.SqlClient . Since the Import of System.Data.SqlClient was failing, all of my Sql classes used in declarations on the page -- SqlConnection, SqlCommand, SqlDataReader -- were undefined.
To fix it, I just had to use a full reference to System.Data.SqlClient.SqlConnection when declaring my very first variable for one of those classes on the page:
Using conn As System.Data.SqlClient.SqlConnection = New SqlConnection(GetConnectionString())
By changing just that first declaration on the page, it fixed the compilation error on the Imports line and all subsequent declarations on the page. (Even stranger, after building the project once like that, I was able to revert the declaration back to just referencing SqlConnection, and the Import worked and the page is compiling fine. So it may have been a temporary issue unrelated to my temporary fix)
I had already fixed this problem once I got to the point of googling this, and all I had to do was delete and re-add the reference in the solution explorer
I am trying to use the generic DbSet class. I have tried adding the following references so far to my solution because the MSDN documentation states that DbSet lives inside System.Data.Entity:
However, as shown below I still cannot add a reference to System.Data.Entity, the only suggestion intellisense has is EntityClient which does not contain DbSet:
Resharper/Intellisense is not giving me any other suggestions of namespaces I could possibly add.
I have tried cleaning and rebuilding my solution, and I am using the .Net Framework 4 full version (not the client version).
I have tried using NuGet to search for EntityFramework and have found one result which I have added to no avail as is show below:
What DLL file do I need to add to my solution to add a reference to System.Data.Entity and use the DbSet class?
Thanks
The same MSDN reference page that you mention says that you need to reference EntityFramework.dll in your project.
Note that namespaces and assemblies are not the same thing. The following statement is a little over-simplified, but you can think of namespaces as residing inside (or becoming available by referencing) an assembly.
So, once you've referenced the assembly, you will still need the using System.Data.Entity; directive.