I am developing an API in WebApi (current version 2017), which is using Antaris Razor engine 3.10. Today's current non-beta version.
A concern was raised that the "Razor engine is powerful" and could make a REST call. Is this possible?
I understood it to be a templating engine. Is it possible that during the compilation stage or the run stage that the engine could make a REST call?
I am not rendering the end result of the template in the browser. It is used only to format a JSON/XMl string content to post to a subsequent REST call in the compiled C# API that I am building.
Does the Antaris Razor Engine have the ability to make a REST call internally?
The answer is yes. The Antaris Razor Engine can make a REST call during the run stage.
It is essentially able to run .Net code. It does more than data binding and token replacement. It joins a model to your template and runs any .Net code you can get to compile.
Some things are slightly more difficult to use, for instance, an implicit conversion to a string doesn't really work. I found .ToString() is required to be called where it may not be if you were writing in Visual Studio. Also, null checking sometimes throws an Object Reference error, even when done as recommended by the project. I found deserializing the object model to a dynamic made null checking more reliable.
All in all, it is a great project, with a ton of power. A little quirkiness won't stop me from using it.
Related
I've found myself in an interesting position. I currently use the latest Unity container, I'm on asp.net core 2.2, and I use application insights. As such, I have configured DI in my web app to use unity instead of the out of the box DI provider in core. I also use Application Insights and use the IWebHostBuilder.UseApplicationInsights extension to spin up AI for my app.
With all this in mind, I have a piece of code whose constructor takes in IHttpContextAccessor so I can access the HttpContext. It was working great. Then, I had another small app that I was trying to reuse the functionality, and the HttpContext was null coming from IHttpContextAccessor. With a bunch of guess, test, revise, I found that IWebHostBuilder.UseApplicationInsights seems to initialize that Request property (HttpContext) on IHttpContextAccessor. If I commented out that AI extension, I would get null; uncomment it, it worked.
I've started to look through the AI code to figure out what exactly they're doing, but honestly, with all the dependencies and pipelines and all that, it's a pretty daunting task. I was hoping someone could point out where/how AI is doing this so my code doesn't NEED AI in order to work. All help would be incredibly awesome.
Use AddHttpContextAccessor extension to add it to DI. HttpContextAccessor is not added by default due to performance impact.
services.AddHttpContextAccessor();
After some struggle, and hoping this post would enlighten me on the AI ask, I found that I didn't need to replicate the AI mechanism, if there's even one at all.
Originally, I was accessing the IHttpContextAccessor via code in the view (Razor). I have an abstract factory pattern I was using to instantiate IHttpContextAccessor via Unity (this pattern came over from my .Net Frame work days). Once I moved that code back to the controller and used proper .net core DI to get the dependency via the constructor, everything started working.
There must be something there I'm missing, but I have the code working so I'm happy. If someone could shed light on why one way works vs the other, I'd be happy to hear it.
When you enable application insights by calling .UseApplicationInsights(), it adds HttpContextAccessor. There are many components in ApplicationInsights which require HttpContextAccessor injected to it. eg: ClientIpHeaderTelemetryInitializer.
This is the exact line where this is occuring:
https://github.com/Microsoft/ApplicationInsights-aspnetcore/blob/develop/src/Microsoft.ApplicationInsights.AspNetCore/Extensions/ApplicationInsightsExtensions.cs#L137
I just upgraded my project from ServiceStack 5.1 to 5.5.1. Now where I am using TemplateContext from ServiceStack.Templates it tells instead to use TemplateContext. Needless to say, this is likely a mistake in the description for the Obsolete attribute. What is the appropiate replacement for TemplateContext now in ServiceStack 5.5.1?
The depreciation message should’ve said to use ScriptContext instead.
In the latest ServiceStack v5.5 Release ServiceStack Templates has been rebranded to #Script.
The section on Migration to new Script API's explains how to migrate in more detail:
Migrating to the new APIs is fairly straight forward:
Change using ServiceStack.Templates; to using ServiceStack.Script;
Any classes with TemplatePage* has been renamed to SharpPage*
Any other class with a Template* prefix has been renamed to Script*
This change doesn’t affect any of your existing #Script source code whose existing syntax and available filters/methods remains unchanged.
New Terminology
The primary rationale for the rebranding was so we’re better able to label, describe and document all of #Script different features easier, so when referring to Templates View Engine we’re now calling Sharp Pages which is a better corollary to “Razor Pages” which it provides an alternative to.
Other re-branded features:
API Pages are now called Sharp APIs
Web Apps are now called Sharp Apps
Template Filters are now called Script Methods
Template Blocks are now called Script Blocks
The collection of methods you inject in your scripts like TemplateRedisFilters and TemplateDbFilters are now referred to as “Scripts” where they’ve been renamed to RedisScripts and DbScripts.
I'm designing a new architecture in Azure. It's a multi-tenant SaaS application with an ASP.NET MVC front end and some application specific data in blob storage. I need to perform some background processing on this application data at certain points. This is currently only possible using some legacy C++ code (I can't realistically rewrite this in C#).
One thought I had was to push any background jobs onto a queue and use Azure functions to service the queue as and when a job gets pushed onto it. The sticking point is the native code. I can certainly expose methods in the native code that C# can p/invoke, but can Azure functions call onto native DLLs and if so is this a sensible approach?
The code does run in a sandbox, but this approach should work. (you may want to consider exposing the relevant API in a managed assembly that would in turn be consumed by your function).
Whether you'll run into limitations with the sandbox is dependent on what your code is doing, but you can learn more about the sandbox and its restrictions here: https://github.com/projectkudu/kudu/wiki/Azure-Web-App-sandbox
I hope this helps!
mfcu100.dll likely depends on some other DLL inside the VC++ 2010 Redist
Most probably msvcr100.dll and msvcp100.dll.
If you include all the dependency DLLs along with your native binary, it should work.
first things first , i have seen nwsnapshot. and its not helping.
i am building an inventory management system as a desktop app using node-webkit . the project being built is using compoundjs (mvc javascript library). which have a definite folder structure (you know mvc) and multiple javascript files inside them.
the problem is nwsnapshot allows the app to have only a single snapshot file but the logic of application is spread over all the folders in different javascript files.
so how do i secure my source code before shipping it to client? Or any other work-around Or smarter way (yes, i know about obfuscating).
You can use nodewebkit command called nwsnapshot to compile the javascript code into binary which will be loaded into the app without specifying any js file
nwsnapshot --extra-code application.js application.bin
in your package.json add this:
snapshot: 'application.bin'
It really depends on what you mean by "secure".
You can obfuscate your javascript code fairly well (as well as potentially improve performance) by using the Google Closure Compiler.
I'm not aware of any off-the-shelf solutions to encrypt/decrypt your javascript, and honestly I would question the need for that.
Some people think they need to make it impossible to view their source code, because they're used to dealing with compiled languages where you only ship binaries to users. The fact is, reverse-engineering that binary code was never as difficult as some people think it is, so if there's any financial incentive, there is practically no difference between shipping source code and the traditional shipping of binaries.
Some languages have offered genuine encryption of deployed assets, such as Microsoft's SLPS. It seems to me that the market for this was so small that Microsoft gave it to a partner (just my view). The truth is that most customers are not interested in taking your source code; they're far more interested in your ability to service and support that code in an efficient manner, while they get on with their job.
You may consider to merge the JS files into one in the build process and compile it.
Can you use the InternalsVisibleTo assembly attribute in a AssemblyInfo file of a MonoTouch Library to allow MonoTouch Unit Test (Touch.Unit) access to the internals of the MonoTouch library?
This is something that is great to use in non-MonoTouch world to allow testing of internals without having to jump through hoops. However I am not able to get it working with a MonoTouch Unit Test. So before I go any futher I figured I would ask if it is even possible, since this is an iOS Application that is the test runner, so not sure if an iOS application which is compiled to native code can even do this.
Yes, it should (or it's a bug) even if I do not recall trying it myself.
The key point is that [InternalsVisibleTo] is mostly a compiler trick and it is supported by the C# compiler (smcs) shipped with MonoTouch (as it's used inside the BCL). As such there's no reason why it should not work from a Touch.Unit-based application.
Now keep in mind that all other rules still applies. E.g. if the the managed linker is enabled when all unused code will be removed (even if marked with the attribute).