Currently we were using SmartAssembly from RedGate to obfuscate out .Net Framework based libraries and it worked just fine.
However, in the past months we started working on supporting .NetCore and .NetStandard to be able to scale our product and noticed that we cannot longer obfuscate the resulting libraries because SmartAssembly doesn't support it yet.
Dotfuscator from what I know, could do the job, however it's not taking care of the relationships between dependencies so it's not actually a full obfuscation.
What other tools is the community using to achieve this purpose? I'm interested in free and commercial tools as well.
Related
I'm trying to add a full framework class library as a project reference to asp.net core 2.0 MVC project and getting the below error.
Project XYZ is not compatible with netcoreapp2.0 (.NETCoreApp,Version=v2.0).
Project XYZ supports: net462 (.NETFramework,Version=v4.6.2)
I have updated to the most recent version of Visual studio i.e, 15.3.5.
Is it even possible to reference 4.6.2 libraries in core 2.0 projects?
The first thing that you can try is to compile the library you want to consume as netstandard2.0.
Theoretically (according to the .net standard documentation), this will make it compatible with projects using net461 and later as well as netcoreapp2.0 and later.
In practice, sometimes you will end up with a problem with one of your dependencies that don't provide the same library version across different compilation targets.
In such cases you may simply need to add the .net core 2.0 as a target framework for the XYZ library.
The xml tag listing the targets is <TargetFrameworks> in the XYZ.csproj file and is not handled by the Gui of the project's properties.
So I would give a try at editing the XYZ.csproj by hand and add or replace what's listed as <TargetFrameworks> with netcoreapp2.0.
If you are adding it as additional target you need to separate them with ';' as in
<TargetFrameworks>net462;netstandard2.0;netcoreapp2.0</TargetFrameworks>
More details about this in this Microsoft doc.
Please keep in mind that this will trigger multiple compilations and will slow your build consequently...
It should be. Microsoft announced a ".NET Framework Compatibility Mode" with the release of .NET Standard 2.0. However, they didn't go into great detail about how it works exactly, or what to troubleshoot if it doesn't. Additionally, they only specific talk about it in relationship to Nuget packages, so it's possible there's some role Nuget is playing in the process, as well. Unfortunately, I've been unable to find any additional information about this feature outside of the announcement post.
That said, Microsoft's explicit recommendation is to not rely on the fact that your .NET Framework library may just happen to work in .NET Core; instead, you should be actively porting .NET Framework libraries you control to .NET Standard. I'd say you're likely going to spend more time trying to figure out why it doesn't "just work" than you would porting your code, so that it will definitely work, and be future-proof to boot.
The following solution worked for me.
Deleted bin and obj folders from all the projects in the solution, rebuild and if it still doesn't work try changing browser from debug options. for eg. If you already have chrome as default browser in Visual studio, switch to Edge or Firefox.
I am trying to generate Well formatted Excel files from .Net Core and found ClosedXML library which runs only on .Net 4.61
I already tested the following libraries which work on .Net Core
OpenXML - Too many codes for a simple task and difficult for me to use
SyncFusion - Public / Government Organisation cannot use for free.
I changed the target to Net461, do the dotnet restore and all my codes are still running as usual and I could generate the Excel file with ClosedXML too.
What I would like to know is, is it a good approach? This is not a one-off small project and I am likely to maintain this website for another 3-4 years at least.
Is there any potential to lose the new functionalities and not able to use new Libraries from .Net Core in the future?
Or should I create another separate website running on Net461 and call that URL from my .Net Core app? So, I don't need to worry about losing new .Net Core functionalities in the future.
There is obviously no way to know the future, but the biggest thing you get with .Net Core over the full framework is the ability to run the app cross platform. So if cross platform isn't a concern, then going with the full framwork shouldn't be an issue. There is no question that the full framework will be fully supported for the 3-4 year time horizon you mentioned, in fact I think most developers would feel comfortable using the full framework even for a project with a much longer time horizon.
With regard to missing out on new .Net Core features, many of the features can be accessed even from libraries compiled for the full framework. For example I use the new encryption libraries found in Microsoft.AspNetCore.Cryptography (that are part of .Net Core) from my full framework class library. The net .Net Core libraries are just Nuget packages and as such can be referenced from non .Net Core projects.
I've seen videos introducing ASP.NET vNext and been keeping up with the recent announcement blog posts, but detailed information on what's been stripped from the full framework appears slim. Here's what I think I know so far:
It's much smaller (11MB vs >200MB): http://davidzych.com/2014/05/24/getting-started-with-asp-net-vnext/
Strong naming is gone: http://jeremydmiller.com/2014/06/09/final-thoughts-on-nuget/
It's dumped System.Web
It includes a merged MVC and WebAPI (however I don't believe this is part of the framework itself but rather dependencies that can be specified)
Dependencies are completely managed through project.json, to the extent that the base
Are we basically looking at a framework that basically includes nothing more than what's in mscorlib in the full framework, with all else delivered via package management? And if this is the case, why would one need to target the framework specifically, as described here? http://blogs.msdn.com/b/webdev/archive/2014/06/17/dependency-injection-in-asp-net-vnext.aspx
The reason they specifically target NET45 in the link you supplied is because AutoFac is built for and has a dependency on .NET 4.5. Without NET45 the code wouldn't compile.
My assumption is that once vNext gets closer and closer to release the Autofac (and StructureMap, and Castle Windsor, and ...) will release a version that targets the cloud optimized framework to remove the dependency.
As far as I understand, .Net Framework is the fully framework we know and love with all the Windows implementations and lots of code we don't normally use, like they explain in some videos an XML parser.
In .NET Core they removed all the unneeded implementations/dependecies and only left the basic ones. which also enables cross platform (not yet), so in the future one could think as the only framework : CORE Framework, and run on any device. Their february community standup give a lots of information and insight on their objectives and goals.
I see this as a transition, when some features are available only on the full Framework while in the futures one might expect to see all features available for .NET Core.
From a Microsoft perspective, if they want to release lets say Entity Framework for mobile (EF7 is aiming at that) they must get rid of all the windows implementations, on EF and it's dependencies (Framework). So they created a non-windows dependency on the framework, which also helps the multiple framework install and remove some problems with updating the framework by having them mostly isolated from the system, lying in the application. New problems will come like multiple copies of the same framework on one machine per application, that's why they are working on something called Smart Sharing.
This post may help you and give you some insight specially this part :
The structure of .NET Core is comprised of two major components which
add to and extend the capabilities of the .NET Framework as follows:
Runtime:
Built on the same codebase as the .Net Framework CLR. Includes the
same GC and JIT (RyuJIT) Does not include features like Application
Domains or Code Access Security. The runtime is delivered on NuGet
(Microsoft.CoreCLR package)
Base class libraries:
Are the same code as the .Net Framework class libraries but do not
contain dependencies so have a smaller footprint. Available on NuGet
(System.* package)
and I guess you already read Introducing .NET Core from Microsoft.
Regarding your concern about specifying a specific framework is because right now, not everything works on Core CLR so you must choose which one to use, or you can target both and use different implementations.
As of right now, CORE only runs on Windows; the mono framework doesn't have a SQLLite provider for entity framework but it does on Core, so you can use an InMemory or Azure EF provider for example, and choose depending on the enviroment your application is running.
As Scott Gu says on the community standup, they envision a future where there's no mono framework or full framework, there's just Core, but that will take time if it ever happens.
I can't find an original source other than a comment by David Fowler (I believe) on a presentation from NDC, but CoreCLR used by the K Runtime is actually a reincarnation of the CLR used by Silverlight 2. It was used because it's small and designed to be cross platform. There is some additional information here: https://stackoverflow.com/a/25720160/113225
So far i've only been using webforms. But me and my friend would like to try out the MVC architecture. Some questions:
Is there any downside with the free version of visual studio VS professional? I can get the professional version from work but is it worth the effort?
I would like to use Entity Framework and the latest version of MVC + the razor view engine. Does this need to be downloaded separatly?
As far as versioning is concerned; is tortoise SVN suitable for a small project on 2 persons?
Any help is appreciated, thanks.
SVN is ok as a repository in my experience. If you are using Visual Studio there is a decent plugin so you can use it from within the IDE, rather than from within Windows. If I am using SVN, it is what I use! More details here.
MVC3 can be downloaded here
Entity Framework can be installed via Nuget (PM> Install-Package EntityFramework ) or a quick google will show the download locations (I think there is version 4.3 and a CTP of version 5)
Free version will work, not sure if there are any differences.
Yes you need to download it seperately
Why wouldn;t it be?
Not that I know of. It's a good way to start. I know earlier versions didn't allow plugins but not sure about the latest versions.
EF will come with the .NET SDK (VS) so no need there. You can get MVC3 from the Web Platform Installer (http://www.asp.net/mvc/mvc3)
I use Tortoise SVN on a team of 4 people with no issues at all. Just make sure you all know good rules for source control management.
I'm wondering about best practices to develop ASP.NET MVC apps with an option to deploy on Linux. If you are creating these kinds of MVC apps,
What Linux/Mono platform are you targeting?
How much of the development are you doing on Windows and how much on Linux?
Are you using an ORM to abstract the database? Which one?
Are you running a build engine on Linux? What about tests?
What other tools are you using?
How much additional work has it been to target Linux in addition to Windows?
What ugly or pleasant surprises have you encountered?
The company I work for targets Mono on Linux as our main deployment environment. Thus there is no "additional" work - we provide the whole stack, from hardware, through operating system (customized and trimmed) to applications. Using Open Source gives huge savings for us and our clients (and yes, we do contribute back to the OS Projects we rely on).
The important thing is to constantly test using your actual target (sorry, Mono on Windows doesn't count). Sure, developers use Visual Studio, but the continous integration (using CruiseControl.Net, you'll need Mono 2.4.2 to run it on Linux) is done both on Windows and Linux, testing all Mono versions we expect to work on (it got much more stable recently, but still, regressions do happen between releases). It's quite easy to run parallel Mono versions on one *nix system, you can even include an svn snapshot build if you prefer to catch upstream regressions early. If you don't roll out your own distribution, then remember that most Linux vendors ship Mono with custom patches - this has caused problems for us before. Also, many distributions have a lot of lag updating Mono, and this is a rapidly advancing project.
For database layer we use mostly "plain" ADO.NET - Oracle (with dotConnect for Oracle, they support Mono) and SQLite (Mono ships with a working connector). I have also used the official ADO.NET Driver for MySQL (Connector/NET) and it, too, works well. ORM mappings are more tricky, but NHibernate is usable (keep in mind that they do not support Mono officially).
As for the build engine and tests - NAnt and NUnit are well known and well tested. With most recent versions of Mono xbuild (clone of MSBuild) actually got usable, but prepare yourself for contributing quite a lot patches if you decide to use it for more complex scenarios.
Write tests. Lots of them. Be prepared to contribute patches and bugreports, and if you use commercial components - make sure the supplier officially supports Mono.
Nathan Bridgewater's blog has some nice articles showing, among other things:
running MVC3 with razor on mono
migrating ASP.NET MVC from Windows/SQL Server to Linux/MySQL
installing and running MonoDevelop
installing mono from source
http://iws.io/get-mvc3-razor-running-on-mono/
Take a look at the Mono project. Sounds like that is what you are looking for. If I remember correctly, they have ASP.NET MVC integrated into it now.
I have never worked with Mono, but from my understanding there are not many differences.