Is it possible to develop a Web Part without usage of .NET technologies? I'm looking for possibilities of integration of legacy (for example java) applications into SharePoint.
Any valid way for .Net CLR to call your code will do what you want. However with that said, it is likely to be very low level, very obscure and very difficult to do.
A more straightforward approach to reusing your Java or whatever code was if there was some sort of public cross language interface for you to exploit in your .Net skeleton. The obvious answer is a REST or SOAP wrapper around the Java code but it doesn't have to be that. It could be CORBA or JMS or all sorts of things.
Even if you want to integrate Java apps, the web Part will be coded in .NET.
There are a few ways to accomplish this, all of which involve a .NET web part exposing external data. All of your common integration methods apply including exposing the legacy application through web services or even directly accessing the database - you could use whatever your organization is accustomed to with other integrations.
Another possible option, depending on your SharePoint version is the Business Data Catalog (2007) or Business Connectivity Services (2010). These options, while can be a little bit of a pain to set up (though third party tools are available) do allow for some automatic integration of other applications into SharePoint.
Related
Good day, I've been using ServiceStack for many years, I currently designing and planning a rewrite of an ASP MVC (Razor) project. #Script seems to be an almost perfect fit, without hands-on experience of the technology I have some doubts and questions.
My question is how relevant is #Script today and what is the future plans of this technology. I ask these questions because when I looked at GitHub example I noticed that there is not a lot of activity, and searching the internet I am also not finding a community around it.
As #Script's author I would say that #Script is a complete library for what it's designed for as an embeddable sandboxed .NET scripting and templating language that's ideal for exploratory programming with seamless integration into .NET APIs (including Win32 APIs) that includes a vast built-in library (1000+) of filters that's easily and highly extensible to the point that it's even able to natively support multiple languages (inc. built-in LISP Repl) within the same page that's been a joy to develop with thanks to its built-in Hot Reloading support where changes are instantly visible upon save - so technology-wise IMO it's pretty great.
If we were to compare it to comparable libraries in other languages like the Ruby's Liquid it should be pretty clear that #Script is vastly more capable where it scales from a user-friendly templating language to a powerful scripting language where it's capable of developing entire Windows Desktop Apps that fits in a Gist.
On the activity front, Liquid is also an established library with low activity with only a handful of commits in 2021, the difference is that it's vastly more popular and used in popular products like Jekyll as used in GitHub Pages which ensures it will always have a rich, vibrant ecosystem which is the most important indicator for assessing a technology's longevity.
Technology not as important as ecosystem
However in the end the technology doesn't matter nearly as much as its user base, community and ecosystem behind it which is where #Script is sorely lacking. Unfortunately this is the reality of libraries that compete Microsoft's defaults like Razor which are exclusively promoted for .NET and will always retain the majority of adoption in .NET.
#Script is a "complete" library in that I've added all the features I planned for it and there's basically nothing I can think of to add to it to make it more appealing, but facing the realization of its indefinite lack of adoption I wouldn't recommend using it for large living (i.e. multi-year) Websites, given it will never have the community and adoption enjoyed by other ecosystems since the benefits of a community and ecosystem are ultimately the most important attributes in order to continue investing in a technology.
Continue to be actively supported
Like all of ServiceStack, #Script is still an actively supported library with no outstanding issues so it's safe to use in that any issues will be promptly resolved should you wish to.
Website Development Recommendations
I'd say it's still a fine option for smaller definitively-scoped projects since its compile-time-free and Hot-Reload makes for a very productive Dev UX for server-generated dynamic pages. However even then I'd first evaluate if a static generated framework like Jekyll, Hugo or other popular static generators would be more appropriate since they enjoy a vibrant community and a statically generated site results in a more performant, resilient and cheaper to host and deploy website.
Static Site Generators
Having recently redeveloped the servicestack.net website to split it out into using Jekyll for static content and ServiceStack.Razor for dynamic content, my recommendation for large websites with large static and dynamic components is to use a static site generator for its static content which yields several benefits:
Although it does require a fair bit of overhead to setup as you're effectively maintaining 2 different websites however it greatly benefits if the static content is actively updated as there's a lot less friction to change and update content on a static generated site then a dynamic one and it results in a superior end user UX thanks to CDN Edge caches that's also cheaper to host from free sites like GitHub Pages and Netlify.
In order to preserve existing URLs we needed extra functionality not possible from a static host so our static content is deployed to a S3 bucket where we use CloudFront for CDN edge caching, CF Behaviors for proxying "external static" routes to our .NET5 dynamic website and a CF Function for supporting pretty URLs. For internally deployed websites you'll be able to accomplish similar functionality with reverse proxy and redirect rules.
SPA or Razor
For small websites or mostly dynamic websites that wont benefit from a content site split I'd recommend either an SPA Project Template if you prefer TypeScript and an established SPA FX like Vue, React, Svelte or Angular or Razor or MVC if you instead prefer C# server generated websites.
Progressive Enhancement
My personal preference is for read-heavy dynamic sites to use ServiceStack Razor utilizing API First Development approach so that all writes are made to the same clean ServiceStack APIs that Mobile and Desktop Apps would also call. This typically involves using some kind of progressive enhancement like our Client TypeScript Validation example which utilizes the Form & Validation Binding in #servicestack/client to take over <form> submissions to perform TypeScript API calls and apply any validation errors back to the Form's UI.
The Client jQuery example accomplishes the same thing without the tsc -w watched build step whose form & validation binding utilizes the older jQuery ss-utils.js library but it does mean you'd need to author logic in an older broadly ECMAScript 5 supported version of JS.
Future of #Script
As I don't expect #Script Pages will ever achieve any meaningful adoption required for self-sustained active development, it's unlikely we'll continue in investing in further development for usage in dynamic websites (i.e. the script project template), it's a complete and extensible library so further development isn't strictly necessary as it can be easily extended with your own local Plugins, Methods, Transformers and Blocks. But it does mean we're unlikely to be creating and including new methods/plugins designed for dynamic websites in the library OOB.
Still a critical ServiceStack component
#Script is still a critical component of ServiceStack where it's used to provide integrated SPA templates since it's able to render dynamic websites from static *.html pages in npm dev hot-reload servers which can't use Razor's *.cshtml pages. It's also what makes ServiceStack's Declarative Validation possible where validation rules can be defined on dependency-free DTOs as it allows defining binary-decoupled logic in dep-free attributes. It's also what makes vuedesktop.com Desktop Apps like ServiceStack Studio possible as well as command tools like Post Command - HTTP API Command Line Utils and cross-platform dotnet scripts which makes usage of its internal functionality, so it's going to continue on as a actively developed & supported library.
Good future use-cases of #Script
However I'd limit any #Script usage to where it excels, e.g. as an embeddable scripting .NET sandbox given it's more versatile & flexible than Razor for tasks like Rendering Emails, authoring & rendering Live Documents (e.g. if needing to maintain live user-generated reports in an RDBMS) or as an embeddable Template, JS or LISP DSL or for evaluating adhoc JS/LISP Expressions or .NET logic.
Future replacement project templates
For developing server-generated websites with ServiceStack we're looking at shipping a couple of new templates which encompasses our latest recommendations (e.g. embracing an API First Development style), if they result in a great Dev UX we're looking at:
An Integrated Static generated (e.g. Hugo/Jekyll) + Dynamic Project template
An API First MVC Pages + ServiceStack template with integrated progressive enhancement
Please follow #ServiceStack to get notified as soon as they become available.
I need to build a web based application that can list available ssid in the area.
From my understanding, these probably can do what i want
Java applet
Adobe Flash
However, Im not sure whether these can do or not
HTML5/JavaScript
Java Web Start
I'm a .NET developer and I'm not familiar with these web technologies.
Are there any other method to get a list of SSID that i have not mentioned?
Thanks.
You'll never be able to list available SSID's with HTML5, Javascript, or any other strictly web-based technology. That's a very low-level task and won't be natively possible in any browser for security reasons. That being said, you may be able to draw on some technology like Java Applets, ActiveX, or even Silverlight 5 if I remember correctly. I don't know your project requirements, but you're better off creating a native application for this type of feature. If this application is being used by/sold to the general public, you're setting yourself up for a lot of headache by going with Applets/ActiveX/etc.
Can existing .net application(in C#) be converted to MonoDroid? or
Can we port an existing .NET web app to Android using MonoDroid?
MonoDroid is intended to allow you to develop applications in C# as opposed to Java; not as a means to drop an existing application into place.
You asked about a web app, but I'm assuming you mean an ASP.NET web app, which wouldn't map to the Android API, and couldn't simply be copied over. Even taking your HTML and dropping it into something like Titanium would still require a lot of JS tweaking to make it work.
I have a feeling you're looking at a re-write. Maybe if you can provide more details (is this an ASP.NET app, etc.), I could give a better answer.
Yes no problem. But it wouldn't be an automatic process, nor a particularly simple one. All the UI elements, persistence stuff and so on (the platform specific parts of your application) will need to be redone. Depending on your app, and how it is written, this may be a major part, or a relatively small one. The more corners that were cut originally, the more it will cost to port over.
In addition to Tom's answer, I would say it has some limitations(link 1 and link 2) . I blogged some other interesting moments here.
Here is a good example of cross-platform mobile application (monoDroid, monoTouch, WP7).
When I create an Azure ASP.NET application, by default .NET trust level is Full trust. I always change it to Windows Azure partial trust which is similar to ASP.NET's medium trust level.
You can do it either by using GUI when you select Properties on the Role or by setting enableNativeCodeExecution to false in the definition file (.csdef) just like below:
<WebRole name="ServiceRuntimeWebsite" enableNativeCodeExecution="false">
As a security conscious developer I want by default to run my application in partial trust mode that provides a higher level of security. If I need to use something like Reflection or P/Invoke, as a developer I want to make the decision to lower that trust level by myself.
I'm sure there's a reason why Microsoft decided to use Full trust as a default .NET trust level, I just fail to see it. If you know the reason, or you think you know it, please let me know.
Full trust is not only required for P/Invoke for .NET reflection as well. As a bottom line result, nearly all moderately sized apps need full trust because nearly all widespread libraries need it too (NHibernate for example). Actually, I have been asking from the exact opposite question on the Azure forums too.
The issue of full or partial trust pertains to the environment in which your application runs. The more control and/or "ownership" of the environment and assemblies you have, the more acceptable it is to have full-trust settings.
For example, if you create an Azure web site (July 2012 capability) and, mimicking wordpress or Umbraco, your web site allows arbitrary assembly plugins to be downloaded and installed, then it is important to have a partially-trusted environment. It is possible that one of the plugins downloaded and executed, which you don't control or own, contains malware. Not only does this impact the security and stability of your web site, but some may argue it impacts other (multi-tenant) hosted web-sites which have no relation to yours.
Certainly your web site will rely on 3rd party libraries, such as Log4Net or StructureMap, but those are extremely well-known and vetted libraries that are not in question regarding their security impact. Ergo, if you are running an Azure web-role (a much less "multi-tenant" type affair) and you are merely running such "trusted" 3rd party apps, then there really is not an issue with running as full-trust.
Yes, unfortunately it is still very hard (if not impossible) to write large .NET apps that run in partial trust.
We need much better technology and tools (like CAS.NET)
Because Medium Trust is now officially obsolete. If you start a new web project in Visual Studio, it already requires Full Trust (and doesn't work partial trust). Microsoft says: Do not depend on Medium Trust, instead, use Full Trust, and isolate untrusted applications in separate application pools.
Sources:
Stackoverflow answer: Quoted response ASP.NET team
Microsoft: ASP.NET Partial Trust does not guarantee application isolation
Microsoft: ASP.NET web development best practices
A client wants us to develop a Picture Library system for them. The requirements are pretty typical - need to add pictures, tag them with metadata, store different sized versions and so on.
The client is keen on it being developed as a component which plugs into their existing SharePoint system. However, my feeling is that we would be better served building a standalone app - that way we don't have to shoehorn it into a SharePoint page and muck about integrating with SharePoint's APIs.
I am trying to look at this objectively and would welcome any arguments either way that people have.
Using an existing framework like Sharepoint imposes a lot of constraints on the design which makes the software architecture more uniform.
It does require some work on the part of the developer, because the developer does have to understand the API architecture and API's, etc.
However, developing a standalone application is the way that business's software architecture becomes a mix of 200 applications, using 20 different languages/architectures/platforms, half of which were developed by people no longer there - in short, a mess.
Sharepoint is documented, and will be supported probably long after you leave the company. Can you guarantee support for the application that you develop for as long as Microsoft will support Sharepoint?
You should do a cost/benefit analysis of integrating with SharePoint. You have listed some cons for integrating with SharePoint. Here are some pros.
Widely adopted platform.
Existing functionality to store/retreive/update images to data store.
Existing functionality to tag images.
Existing functionality to group several images together and treat as one virtual document (if using SharePoint 2010).
Keep in mind that you can integrate any custom ASP.NET page/application in Sharepoint so you can approach development like a standalone app. Your client wishes might include synchronization with Sharepoint's own picture library functionality and in that case you'll have to work with it's API.
It seems with SharePoint you are already done because it can more or less do what you describe already. What requirements do you have that cannot be met by OOB SharePoint?
I've used picture libraries for something similar before. While they have their quirks you do get a lot 'for free' like a UI, bulk uploading, metadata and 2 alternate sizes rendered.. My biggest gripe is they don't support the datagrid view so I cannot edit list metadata en masse like you can with other list types.