I have downloaded the code effects demo ASP.Net project for VS2013 to test its business rules on one of my own dll. I updated the .net framework from 4.5 to 4.5.1 because my assembly was built in 4.5.1.
But unfortunately when I set the SourceAssembly and SourceType properties to point my dll and class, I get following exception
I am not sure what I am doing wrong.
Thanks.
Sorry guys, I think I missed some dependencies. Adding them to the project resolved the issue.
Related
I have a .NET Standard 2.0 class library project with installed Nuget package System.Data.SqlClient version 4.4.0 and a Windows Form .NET Framework 4.7 project that has a reference to that class library.
Installing the Nuget Package and building the solution is successful. but in runtime every time that the code reaches a method that has any thing from SqlClient assembly inside it (for example an instance from SqlConnection) it gets this error:
Could not load file or assembly 'System.Data.SqlClient,
Version=4.2.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' or
one of its dependencies. The system cannot find the file specified.
Considering this question, I assume the problem was also there in the last major version of the Nuget package.
Edit
I downloaded the Nuget package and unzipped it and from \ref\netstandard2.0 folder copied the System.DataSqlClient.dll manually in \bin\Debug folder of my Windows Form Project and now it works. The exact situation also happened with Microsoft.Win32.Registry package. So I was almost convinced that it's my fault and I'm doing something the wrong way, but when I tested it with System.Drawing.Primitive Package it worked perfectly without any need to copy a dll. Now I'm really confused.
I guess you may have figured it out already but hope it would help someone - wasted some time too on this.
So, in order to make everything work you would need to reference System.Data.SqlClient in Windows Form project that is referencing your .NET Standard Library
From that point everything should be working like a charm
As you already mentioned System.Data.SqlClient.dll was not in output directory.
Sounds like .NET Standard Library haven't grabbed with itself dependent library binary. There is nothing like "Copy Local" option in .NET Standard references so I don't see any way to check or set this behavior too
I had same problem.
Solution for me was adding dependecy from nuget for latest System.Data.SqlClient at my .NET Standard Library project.
I had the same problem. The .NETStandard assembly was added as a reference to my WPF project. I needed to make changes in the .csproj of the WPF project.
The solution mentioned in https://github.com/dotnet/sdk/issues/901 fixes it.
Steps:
Edit your core .csproj file in notepad.
Add the below two lines in each that you find in it.
<RestoreProjectStyle>PackageReference</RestoreProjectStyle>
<AutoGenerateBindingRedirects>true</AutoGenerateBindingRedirects>
Clean and rebuild your solution.
I had a similar problem, bindingRedirect helped in my case:
<bindingRedirect oldVersion="0.0.0.0-4.4.0.0" newVersion="4.4.0.0"/>
I would expect some kind of filter to exists on website or in console.
This isn't easy right now, unfortunately. There's an issue open on the NuGet Github about adding a filter to the website.
Right now, the best way to tell if a package will work with .NET Core is by examining the frameworks it supports in the Dependencies section.
If .NETStandard is listed, the package supports .NET Core via the .NET Platform Standard:
If a package's Dependencies section doesn't mention .NETStandard, or the Dependencies section is completely empty, it does not support .NET Core:
Setup a .NET Core project in the version you want. I keep 1.1 and 2.0 projects around for futzing with this. Then try and add the nuget to the project.
For instance, ASPOSE will NOT add to a 1.1 project, but will add to a 2.0 project.
Easiest route in the short term until they fix this somehow.
Obviously this is no guarantee it still works but gives you a good idea if its api compat.
After having updated a project using Nuget to Entity 6.1.3., this project keeps adding a package for Entity 5.0.0. when Getting latest of that project or when building it.
I already looked with low-level search (fileseek) but can't find any reference anymore in that project to EF5.
Already uninstalled the Entity package and reinstalled, but same result.
What else can I do to compeltely remove any reference to EF5 ?
Problem is solved in the meantime : there was an unloaded! project in which the packages.config still referenced the 5.0.0 framework. I didn't know that an unloaded project was still held into account when building.
I thought this problem was fixed. I'm using Visual Studio 2013 and it is Entity Framework 6.1. I get the error message: PublicKeyToken=xxxxxx is not marked as serializable.
I thought this was fixed. Is it broken again and if so, is there a workaround?
Thanks.
Here is the complete error message when trying to install into a win32 C++ console application. (Built with default settings, no other adds to new build.)
Error: Type
'Microsoft.VisualStudio.Project.VisualC.VCProjectEngine.VCProjectShim' in Assembly
'Microsoft.VisualStudio.Project.VisualC.VCProjectEngine, Version=12.0.0.0,Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a' is not marked as serializable.
Here is the complete error message when trying to install into a C++ CLR:
(Actually, it's the exact same error message.)
Here is the complete error message when trying to install into a General Empty C++ Project:
(Again, same error message.)
Okay, I can finally figure out what you are doing. You are trying to run Nuget to download and install the Entity Framework into a C++ project. Yes, that's going to be a fail-whale. Nuget acquired the ability to install C++ libraries at version 2.5, but that only works for native libraries. Pure C++, not managed code like EF. Being a relatively new feature, it doesn't do anything to stop you from getting it wrong, it doesn't filter the available packages to the kind that can work in a C++ project.
The step that fails is the final one, download and copying files work okay but then Nuget runs a Powerscript script to modify the project properties. Which, for EF, was written to work in a C# or VB.NET project. The VS extension model for C++ projects (implemented by the VCProjectEngine class as reported in the error message) is too different to permit that script to complete successfully.
Do keep in mind that the odds of using EF in a native C++ projects are zero. You'll only have a smallish shot at it in a C++/CLI project. Starting with a project template in the CLR node is a required first step.
The next one is to fool the Nuget installer, add a dummy C# project to your solution and run Nuget to get EF installed into that project. You'll see it adding an app.config file to the project, you need to do the same in your C++/CLI project. And it adds two EF assemblies that you also need to add to your C++/CLI project:
Right-click the project in the Solution Explorer window, Properties
Select Common Properties + References
Click the Add New Reference button
Click the Browse button
Navigate to the dummy C# project's packages\EntityFramework.6.1.0\lib\net45 directory
Select EntityFramework.dll you see there
Repeat to add EntityFramework.SqlServer.dll there.
Be sure to write C++/CLI code to use it. Beware that you'll have a Eskimo's chance to find any. The much saner approach is to create a C# library that uses EF and use that library in a C++/CLI project.
I'm trying to make a hibernate connection to create some reports, but every time I press Test it appears an error window that says org/primefaces/model/UploadedFile, only that.
My classpath already has a jar of my project and the only place where I have the library from the error is inside an entity on the project.
If switch to another's project jar the connection is successful.
I'm using iReport 5.0.4 and Spring 2.9.1.
I'll appreciate any idea of what could be wrong, thanks in advance.
I couldn't figure out what was the problem, so I commented all references to the library and generated the jar that way.
I did it only because there's no related data to the things I commented.