I am using Autofac in a project that is being obfuscated using Dotfuscator. the dotfuscator fails saying it cannot find mscorlib version 2.0.5.0
Is there a way to tell Dotfuscator how to obfuscate Autofac with portable Dll?
Is Autofac team planning releasing autofac with reference to .NET 4.0?
Any other suggestions?
I don't know what version of Dotfuscator you're using, but it does seem that at least as of 4.9.9000 they "know" about Portable Class Libraries. If you aren't at that version and can't upgrade, you might need to contact Dotfuscator support to find out a solution. (Another question of similar nature also pointed to updating Dotfuscator as the answer.)
A similar sort of issue occurs with FxCop analysis and SecAnnotate. To get around those issues with those tools, you need to tell them to ignore version information on certain assemblies (like System.Core and mscorlib). You may need to use an option like that on Dotfuscator if such a thing exists.
PCL can also cause challenges on machines that don't have all the latest .NET patches. Make sure you're patched up.
There is no plan to release an Autofac tailored just to .NET 4.x Autofac is a Portable Class Library so it can support multiple platforms without conditional compilation, making for easier testing and development. It switched away from platform-specific builds as of 3.0 and there's no plan to go back.
If upgrading Dotfuscator and patching your machine doesn't fix the issue, your best bet is to find the Dotfuscator mechanism for ignoring assembly version.
Related
My company has internal components that we deliver via internal NuGet. Now i want to make a Version 5.X of these components which will be breaking a lot from the 4.X versions.
However now if my colleagues browse for updates, the Nuget browser would recommend these new packages.
What i would prefer: If example 4.6 is installed, it would take the highest 4.X version but not 5.0 or above. Making packages for the 5.X path under completely different names would be annoying when the developer choses to upgrade.
Is there a way to mark nuget packages to do something like that? If that's not clear, tell me and i try to clarify.
If your projects are using packages.config, you can use allowedVersions: https://learn.microsoft.com/en-us/nuget/reference/packages-config#schema
There's no way to do this if your project uses PackageReference, but you can upvote (👍) this isse: https://github.com/NuGet/Home/issues/9082
As soon as I've solved one issue with IBM.EntityFrameworkCore, another one has arose. Everything is soooo hard and painful with DB2 and their .NET team...
The problem: I have several EntityFrameworkCore - based projects in the same VS solution, for example MyDb2EfModel, MyMsSqlEfModel, and MyNpgsqlEfModel. (It's kind of a complex data-integration scenario.) On top of that I have a CLI project which references all the three and performs actual data ops. When the CLI project references only MyDb2EfModel project - IBM.EntityFrameworkCore works as expected. But as soon as I add references to the remaining two projects - it simply stops working and throws some misleading exception. The exception happens because overridden DbContext.OnConfiguring and DbContext.OnModelCreating methods aren't called anymore. When there's only one reference (MyDb2EfModel) the methods get called as expected, and everything works. But with all three library projects referenced - they aren't called anymore.
Let's also note that the mentioned methods get called on DbContext instances from MyMsSqlEfModel and MyNpgsqlEfModel libraries. The only one that stops working is MyDb2EfModel (which is based on IBM.EntityFrameworkCore).
Thumbs down for IBM and their .NET team! It's ridiculous how these guys are making things be 100 times more complicated then with any other DB.
The question is obvious: Does anyone has any experience in a similar scenario, and hopefully any suggestion how to resolve the issue?
Thanks!
I've found the reason. It turned out that it's about Microsoft.EntityFrameworkCore version. Currently available version of IBM.EntityFrameworkCore is 1.1.1.101 (.NET Standard 1.6), and it uses Microsoft.EntityFrameworkCore version 1.1.1 or 1.1.2. It cannot be used with Microsoft.EntityFrameworkCore version 2.0.0 (.NET Standard 2.0) - it throws the exception I was getting.
In the other two libraries I've used Npgsql.EntityFrameworkCore.PostgreSQL version 2.0.0 and Microsoft.EntityFrameworkCore.SqlServer version 2.0.0, both depending on Microsoft.EntityFrameworkCore version 2.0.0 (all in .NET Standard 2.0).
So when I referenced only MyDb2EfModel in my CLI project everything was working because only Microsoft.EntityFrameworkCore version 1.1.2 is referenced and used. But as soon as I add reference to another projects CLI ends up with dependencies on both Microsoft.EntityFrameworkCore version 1.1.2 and 2.0.0 versions, and the newer (2.0.0) is loaded and used. And IBM.EntityFrameworkCore was failing because it cannot use it.
How to solve? Either wait for IBM.EntityFrameworkCore for .NET Standard 2.0, or downgrade other references to ensure that Microsoft.EntityFrameworkCore version 2.0.0 isn't used anywhere (which will cause other headaches).
So although it's not about a bug in IBM.EntityFrameworkCore, IBM DB2 .NET team is still to blame for not having .NET Standard 2.0 at least preview published, although .NET Standard 2.0 is available for almost a year now, recently reaching its "release" version. And there are more things to blame IBM DB2 .NET team for (unrelated to this particular issue).
This scenario goes a bit against the whole way nuget works so what i might be asking for is a hack...
My problem:
I need to have Restsharp and Protobuf-net referred to in a .net assembly that going into SQL-CLR for Server 2008 (so max .net 3.5, framework 2.0).
Restsharp goes back to 3.5 as the lowest supported fwk version.
Protobuf-net 3.5 onwards has a lot of gunk referring to system.servicemodel (and WCF) which i don't need and use and actively want to remove because it causes issues with installing on SQL-CLR. Protobuf-net 2.0 doesn't have this :)
So i've built and tested my code with an assembly targeting .net 3.5 and i installed the restsharp nuget - which gave me the correct reference and i manually added a reference to the protobuf-net 2.0 distro.
This is where i'd like to know - can i (in any way) install the protobuf-net nuget package but still have it reference the .net20 DLL in my assembly which targets 3.5?
The static reference is not a huge deal since protobuf-net has been pretty stable, but i'd like to get the whole setup via nuget if possible.
In the end, this is a workaround as solution to:
protobuf-net version without system.servicemodel dependency?
If there's a better answer to that, i'd be very grateful :)
As far as I know, that is not possible. You could of course create your own custom build and host it on a local nuget drop, or as your own nuget package on the public feed. AFAIK, there's no way to do what you want inside a new nuget folder in the existing package.
I have a NuGet package for a library that is currently implemented only for .NET 4. But I have ported library code to support various platforms (WinRT, SL5, WP8) so ideally I would like to package it as a portable class library (PCL) to simplify the maintenance. But the library is using LINQ to XML (XELements etc.) that requires targeting .NET 4.0.3 and installting .NET 4.0.3 on a client machine.
So I have a dilemma regarding how to target plain .NET 4. If it was not about NuGet packages and I had a control of the user base I could simply state as a prerequisite installing .NET 4.0.3 runtime. However, I don't want to limit the user base in any way, so it looks like I will have to have two versions of the library: portable that targets .NET 4.5, SL5 and WP8 and non-portable targeting just .NET4. What's silly is that both libraries will have exactly the same code since LINQ to XML is of course supported in .NET 4, it's just PCLs that don't have such support when targeting .NET 4.
My first question is whether this seems to be a right strategy? The alternative would be to take away all XElement-dependent code from PCL and have it in non-portable parts, but this does not seem right because the code will be exactly the same for all libraries.
The second question is whether it makes sense to target .NET 4.0.3 from a PCL at all: if I have separate version targeting .NET 4 will users that have .NET 4.0.3 runtime installed gain anything from getting a PCL rather than plain .NET 4 version? I know .NET 4.0.3 has other improvements but those don't affect my library.
Yes, I think the best thing is to create two versions of your library, one targeting .NET 4 and another portable library that targets the other platforms you support. Use source file linking so you don't have to have two different copies of your source code, just two different Visual Studio projects.
You only need one NuGet package though. Put the .NET 4 version in lib/net40 and the portable version in lib/portable-net403+win8+wp8+sl5 (or whatever combination of platforms you decide to support). Then NuGet will install the right one depending on what a project is targeting. NuGet 2.1 or higher is required for this to work for the portable version.
In reference to the question about .NET 4.0.3, it's about giving the consumers of your library flexibility. The people using your library are using it to create applications. Supporting .NET 4 may not be as important to them as it is to you. By supporting .NET 4.0.3 in the portable version of your library, it means that if they choose to require .NET 4.0.3 in their apps, then they will be able to use your library from their own portable libraries and more easily share their app code across platforms.
Does anybody have successfully working module in DNN 6 with the Ajax Control Toolkit?
My modules stopped working when we migrated from DNN 5.x to to 6.x.
Modules compile without errors but I am getting client side script error:
'AjaxControlToolkit requires ASP.NET Ajax 4.0 scripts. Ensure the correct version of the scripts are referenced. If you are using an ASP.NET ScriptManager, switch to the ToolkitScriptManager in AjaxControlToolkit.dll'
Seems like this is conflict with Telerik's controls, according to information that I have found. But I didn't find any info how to fix it.
You should be able to use older versions of the ASP.NET AJAX Control Toolkit, but once they start requiring the ToolkitScriptManager, you're out of luck with DNN (though you'll be out of luck with any version of DNN, since there's not a way to override the type of ScriptManager it uses.
Starting with DNN 6, they use Telerik's RadScriptManager. Previously, you could modify the core code to switch out for the ToolkitScriptManager, but now switching out might cause other issues.
It could work together, but you'll need do some modifications to the core of DNN.
Here the list of things to do:
Check that you're using latest version of .Net 4.0 binaries of AjaxControlToolkit (I was able to let it work for DNN 6.0.1 with Telerik 2011.01.519 and ACT September 2011 v4.1.50927)
Check that in your web.config you have assembly binding redirects for System.Web.Extensions and System.Web.Extensions.Design to the version 4.0
Take DNN source package, find Library\Framework\AJAX.cs, locate method AddScriptManager, instantiation of RadScriptManager in it, for the version 6.0.1 look into line 54. Add one more property initializer:
EnableScriptCombine = false. Compile it (in Release configuration, of course), take DotNetNuke.dll and drop into your DNN installation.
You should be done.
Credits goes to Telerik support, despite it's stated there that it should work out of the box starting from 2010.1.625. Not sure, did I get them wrong, or they just reintroduced this bug.
P.S. DNN support promises to release version 6.1.0 in November with updated Telerik controls, which should fix this issue, at least on their opinion.
Just checked with nuke 6.1 and the last version of jaxcontroltoolkit - still the same error.
It looks like it's not supported anymore. Sad:(