I can see my entities on the left panel, can see all related to them as columns and relations to other entities.
when try to select then entity to take(50) I get this error
An assembly with the same identity 'System, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089' has already been imported. Try removing one of the duplicate references.
got no clue where to start on this error...any help? thanks
(if I right click on linqpad editor to go into Query properties the two tabs have nothing on them)
I have seen this before and it was indicative of me adding references to my own libraries which were built with the .NET 3.5 Framework and using them by referencing them in LINQPad 4.0.
If you are adding reference to your libraries, you should use version 3.5 of LINQPad. I actually have both installed into two different sub-directories with a 'link' to either on my desktop/quick-launch bar.
Perhaps the query that you are using (if you based it on an earlier one) was created with a different version of LINQPad.
Related
ExcelRichTextHtmlUtility does not appear in the EPPlus 4.5.1 library (or 4.1 for that matter). I see it's in the code in source control but doesn't get shipped I guess. Is there a particular reason or maybe I'm doing something wrong.
It's in the source code but not compiled as part of the project anymore. When I include ExcelRichTextHtmlUtility.cs, the following line does not compile:
s = System.Web.HttpUtility.HtmlDecode(s);
In taking a look at the project settings, EPPlus targets the .NET 3.5 Client Profile framework. The Client Profile is a subset of the framework which for example does not include System.Web, so HttpUtility cannot be used so they must have just simply excluded the class.
I couldn't find any reference to exactly when and why this was changed so this probably does not completely answer your question.
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 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.
I'm very new to this so I apologise if my question isn't well structured or just in the wrong place, etc. I've had a good look for solutions to this and tried a number of different approaches but haven't found anything that works so....
I have a solution that makes use of Nhibernate, and consequently must use log4net V1.2.10.0, which comes in the log4net/2.0/ folder. However my solution also links to a number of other solutions, to which I have very limited access. These make use of the same log4net V.1.2.10.0 but in folder: log4net/1.2/
When I run my solution I get this error.
{"Could not load file or assembly 'log4net, Version=1.2.10.0, Culture=neutral,
PublicKeyToken=e27b8fa57f63a98d' or one of its dependencies. The located assembly's
manifest definition does not match the assembly reference. (Exception from HRESULT:
0x80131040)":"log4net, Version=1.2.10.0, Culture=neutral,
PublicKeyToken=e27b8fa57f63a98d"}
I have tried to amend the solutions that it is calling, however each time I amend one I get the error within that solution as soon as it tries to use another solution, so I have to amend another and so on. There are simply too many solutions to amend and too many interdepencies with other solutions that I have absolutely no control over for me to be able to change them all so that they use log4net/2.0.
I have found another question ( Referencing 2 different versions of log4net in the same solution ) which I think is basically the same problem, and they amend the app.config with a binding, however I can't seem to get this right, as I'm still getting the same error. The binding I've included in my app.config is this:
<runtime>
<assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
<dependentAssembly>
<assemblyIdentity name="log4net" publicKeyToken="e27b8fa57f63a98d" />
<codeBase version="1.2.10.0" href="2.0\log4net.dll" />
</dependentAssembly>
<dependentAssembly>
<assemblyIdentity name="log4net" publicKeyToken="1b44e1d426115821"/>
<codeBase version="1.2.10.0" href="1.2\log4net.dll" />
</dependentAssembly>
</assemblyBinding>
</runtime>
I'm not sure what the answer to the other question means when it says "You create 2 folder in your project one for each version of log4net. You place each log4net.dll in its corresponding folder by adding an the file to the solution (not with add reference). You can set the copy to output directory property to copy always so that it is automatically copied to the output folder when you build." And would I need to do this to every solution that my solution references?
Ideally I want to be able to make an amendment to my solution which simply means that it doesn't care what log4net any of the solutions are using but they can still pass log messages between each other. I assume this is possible, so any help would be hugely appreciated. Either that or how do I turn off nHibernate's logger so that it doesn't care what log4net I'm using so I can just continue to use the log4net/1.2 that all the other solutions are using. I've tried all sorts of things to turn it off but it still seems to end up trying to find the log4net/2.0.
You're lucky in that you've got the same DLL in two different places, which makes your problem easier to solve. You could simply take a back up and then delete one of the references of the DLL (the \1.2\ version?) and then resolve any broken references in your solution - that should get you to a point that you can compile.
Have you tried NuGet too? You could add a reference to Log4Net and then add a reference to Nhibernate, which would see that you've already satisfied it's dependency requirement and would not need to download another reference to NHibernate.
I'd recommend the learning curve of using NuGet because it is a powerful tool that should make your life much easier in the long run.
Update
Please see my comment about providing your current folder structure to help - incase you can do that; the following should get you started.
To try and do this using just direct file references you may need to move your DLL's around into a better structure. Inside your solution (not project) create the following folder structure under solution items.
\ExternalReferences
\Log4Net\
\NHibernate\
Move a single copy of the log4net DLL inside the log 4 net folder (and delete the other instance) and then move all the NHibernate DLL's you are using (minus Log4Net) in the NHibernate directory. Remove the bindings inside your app.config and then go through each project updating the references to point to the version inside the external references.
The actual location of the files isn't that important, you just need your code to reference a single instance of the DLL and then when it builds they all get copied into the bind folder. You're just running into problems because you have two instances - whilst you are editing your code, etc. NHibernate isn't actually too bothered where Log4Net is; it just has a dependency on it that must be forfilled when it runs.
Update 2
New Version of Log4Net on NuGet that breaks backward compatibility - see the referenced blog post for more info. There is now a 1.2.11.0 version of Log4Net that contains a different strong name to 1.2.10.0, making things just that little harder!
When I add a reference to Microsoft.Office.Interop.Excel on my computer, Visual Studio adds this to the project file:
<COMReference Include="Excel">
<Guid>{00020813-0000-0000-C000-000000000046}</Guid>
<VersionMajor>1</VersionMajor>
<VersionMinor>5</VersionMinor>
<Lcid>0</Lcid>
<WrapperTool>primary</WrapperTool>
<Isolated>False</Isolated>
</COMReference>
There is another developer on the team who gets errors and needs to add a DLL file to the project called Interop.Excel.dll, which replaces the code above with this in the project file:
<Reference Include="Interop.Excel, Version=1.5.0.0, Culture=neutral, processorArchitecture=MSIL">
<SpecificVersion>False</SpecificVersion>
<HintPath>My Project\Interop.Excel.dll</HintPath>
</Reference>
This does work on my computer.
Could you please explain the differences between the two methods, which is best, and how to get the first one working on other computers?
I don't see a problem with your approach either.
Typically VS will generate an interop assembly for COM components automatically when you add a reference to the component. However, when you add a reference to one of the Office components (XP or any later version), a reference to the pregenerated (and optimized) primary interop assembly from Microsoft is added as in your first example. The line
<WrapperTool>primary</WrapperTool>
means that this PIA is used.
If you correctly added the PIA reference the CopyLocal property of this reference should be set to false and the Path property should be something like
C:\WINDOWS\assembly\GAC\Microsoft.Office.Interop.Excel\12.0.0.0__71e9bce111e9429c\Microsoft.Office.Interop.Excel.dll
You will find some more details on interop assemblies in this MSDN article.
To get the first method working it is necessary that the Office Primary Interop Assemblies (PIAs) are installed on the machine. There is a redistributable version available from Microsoft:
Office 2003 PIAs
Office 2007 PIAs
AFAIK, these PIAs only get installed by the Office setup when the .NET Framework has already been installed, that's why there is a separate redistributable for the PIAs.
Note: Make sure that you reference the version of Office that you are targeting. When targeting several versions of Office, you might get some problems however. A solution in that case might be late binding (if performance is not an issue).
I've used Excel automation way more than I would like to admitt, and I have never referenced Interop.Excel.dll. I've always referenced the former. Why is he referencing that, and what errors does he get?
Are you guys referencing the same version of excel (5.0 verses 11.0)? Do you guys have the exact same version of office, service pakcs and all? This could be the differance.
I found the cleanest way to use it, this also allows for multiple versions of the interop, is to create a shared bin\Office Interop\11 or 12\Microsoft.Office.Interop.Excel.dll\ and refeferenced them from the project, works a treat for different version