We have a lot of red tape to handle before any changes to anything can be made on our servers. Hence I'm looking for ideas and/or suggestions for the below situation.
Must generate html from db (MSSql Server) for a static website hosted on IIS 6/7.
No (external) changes should be necessary on the server side except the ones the application/website makes itself.
I tried markdown and it generates everything nicely but I could not find a way to make the above idea applicable with it. I am willing to put all html code in the db for each individual page but it sounds awkward. Should I go with something ASP.NET'ish or a Windows Service or a standalone app to run at a schedule.
Thanks for the suggestions.
ASP.NET Dynamic Data might be your technology of choice.
http://msdn.microsoft.com/en-us/library/vstudio/ee845452%28v=vs.100%29.aspx
However, my advice is that you'll never be able to solve your problems by something like the above. You need to work out how to do releases more often - maybe start with a CI server and start scripting your releases if you haven't already.
Related
Many thanks #Mirko for the reply and comment. So sorry if im not clear myself.
I'll try to make it alot more understandable.
First thing is, I want to create an application for a Data Entry Form on Windows (Windows Form Application .exe). This application required database
and for a database server im thinking about SQL (Need some advise here on the server).
After the Form-Design completed and linked to the database, i want it to be able accessing PDF/PNG and stamping also, For approval purpose. Thus i need some file transfer server for this and some new coding line for this function. (I need a lot of help here especially the coding line).
Please note i've also tried making a form-based application on VBA Excel and use it's sheets for the database. But im struggling on how to make an access for File transfering and stamping (Approval) protocol. Thus lead me to C# on Visual Studio, hoping this coding program could handle such file-embed system.
Edit: Nico, I am not sure this will make a great SO question. Sorry, I cannot provide this detailed feedback in comments as they do not allow enough text. You are asking for advice that is in my opinion too broad. Meaning you really have many considerations here and are in essence asking (I think) how do I build a document management and approval (workflow) application.
You may want to look into document management solutions (I am no expert on those), but many handle approval flows and meta-data on documents well.
I would recommend you carefully consider even your starting assumptions. In my opinion if you are building a green-field application now you should decide between WPF (instead of Windows Forms) and a Web Application (that is in the .NET space) and I would probably recommend ASP.NET Core Razor Pages. If more than one person will use this application I would lean towards the latter strongly as it is more easily accessed and updated.
I am not the best person to answer how to do the Stamping approval part, but you may want to consider either an existing document management solution (maybe DocuSign, etc. as an integration) as they may offer you the features you are looking for out of the box. If not take a look at PDF libraries in the .NET space (I personally used Aspose in the past, but they tend to be expensive).
If you are looking to track metadata about the documents to be uploaded/approved SQL server is often a good choice, but since you are quite literally seeming to aim for document management, more document-centric options maybe a good fit (MongoDB, Cosmos (Azure), DocumentDB (AWS), ...) as they allow you to store arbitrary meta-data.
I have a C# MVC application that uses an SQL database. I need to make this as easy to install/run as possible as it will be being run by people with no experience hosting web applications. The people that will be managing this are able to build servers with a base windows install (Windows2k12, 2k8, ect..) but have no experience with IIS or SQL. I can set it up for them but in the future if it needs to be re-installed I won't be around.
Depending on your options, setting up an automation server such as Jenkins to handle deployments would work. After setting up a deployment job anyone with permission can deploy with the push of a button. Doesn't get much easier than that. It's been a little while since I've set up an MVC Jenkins project but this blog post looks like a pretty good overview of how to set it up.
One of the downsides is that they'd have to keep the server running and make sure that they have a full backup available in case something happens. I'm guessing if you're trying to help them deploy the app in the first place, then they aren't going to be able to set a Jenkins server back up from scratch. But at the end of the day, if something blows up, regardless of what you set up for them, they're going to have to do something to fix it.
EDIT: Just read your other comment, didn't catch they'd need to completely rebuild from scratch (assuming little to no backups). I believe you can automate most of the IIS config and some of the SQL Server setup with Powershell, which can also run on Jenkins I believe. I've never done that myself, though. Here is another blog post on the matter that might be able to help, though.
I am working on a pet project and need to overcome a major hurdle in an application. I have checked countless forums and articles and have only found bits and pieces of what I am looking for, so I hope a more direct approach will help me.
Here's the scenario:
1. The site is actually a game, which uses Javascript/JSON with DHTML on a page that has several IFRAMES - two of which are deeper inside the outside page AND of a separate domain.
There are NO security issues with what I am trying to do. All programming and access is limited to merely simplifying and automating normally access functions only. All authentication and private information is done prior to any access, and only the session information will ever be used, and only to facilitate game operations that the user knows will happen.
The idea is to use the webbrowser control to access the game and provide ordinary access, while the app hosting the browser gets the game session information and makes separate automated calls to the game servers. This has already been done via Firefox using Greasemonkey scripting, and it works well - except that Firefox has a horrible memory leak that eventually causes the whole operation to break down.
The problem I am running into is obvious. I am trying to access the iframe that is technically on a different domain, and the web browser DOM model won't let me in. I have seen enough articles to know there are several workarounds to XSS filter blocks but they are quite vague and vary depending on scenario.
So, I will outline exactly what I need in hopes that I can obtain an amicable solution...
I need to obtain the DOM of a nested IFRAME of a different domain. If need be I could live with just the source, but the DOM and the JS vars would be the most ideal. My strategy here is to use the session information and make HttpWebRequest calls parallel to the web browser in-game. That way I can automate some functions while still playing. It can be done - if I can get the session information and pass it the same way. It will all be done on the same client with the users permission and knowledge, so no security issues.
I would really like it if I could pass information BACK to that IFRAME. One of the major things this project is trying to do is make some visual changes to simplify the look and feel of the interface. It is all in HTML, so changes would simply be adding some in-line styling of JS code...
So anyways, what ideas and suggestions would work best? At this point I am open to all scenarios, but ideally something as simple as possible to get what I need. This is already a huge project :).
Thanks in advance!
If you are in control of all sites in question, you could use postMessage to communicate. Also there is easyXDM which provides a set of transports that also work in older browsers (and automatically picks the best one).
https://developer.mozilla.org/en-US/docs/Web/API/window.postMessage
It's possible to bypass XSS checks and access iframes through IOleContainer, as described here. The sample is in C++, but it should not be a problem to do the same from C# with COM interop.
Maybe a strange and green question, but
Is there anything C# can't do what javascript can...
And considering JQuery?
except for the fact that one is clientside, and the other serverside?
Or am I asking a very stupid question now?
EDIT:
to be more specific: I mean web programming, and indeed maybe a more useful question is:
> What can I do client side that I can't do server side, and vice versa?
> Are there more reasons to use both languages if you keep "server/clientside" out of scope?
> some developers avoid javascript. why?
What can I do client side that I can't
do server side, and vice versa?
Client-side: Javascript runs in most browsers without a plugin. C# requires a browser plugin like Silverlight. Even though it's running on a client machine, Javascript can't read and write files there. C# in Silverlight may be able to read and write files depending on the Silverlight version and what the client allows. Both Javascript and C#/Silverlight can talk to remote servers.
Server-side: since you control this machine, you can do whatever you want - read files, write files, talk directly to databases, etc. Keep in mind there's nothing stopping you from running Javascript server-side. Check out node.js.
Are there more reasons to use both
languages if you keep
"server/clientside" out of scope?
I wouldn't leave the execution environment out of your analysis. If you absolutely need client-side interaction and can't guarantee C# will execute on the client, C# isn't practical. Likewise, if your company runs Windows servers and doesn't want to install Javascript runtimes/compilers, you won't be able to use Javascript on the server.
some developers avoid javascript. why?
Problems with Javascript in a browser are absolutely awful to debug. You're running on a machine that's out of your control - the user may be running an obscure or ancient browser, they may be using anti-virus software that mucks with your Javascript, their browser plugins might muck with your Javascript. It's hard.
This is the cost of doing business on someone else's machine, however. If it was easy, a beautiful client-side experience would mean less. Solving hard problems isn't for everyone but it sure is appreciated when it's done well.
I take it your real question is, if c# can do everything, why should you use javascript at all? The answer here is performance, both perceived and real. The trick here is that to use c# to do the DOM manipulation normally associated with javascript, a browser has to post back an extra http request to the server and tell the c# code what to do. Lets talk about those extra requests. Spread around a lot of users, they add up very quickly and play havoc on your server infrastructure. The "real" performance issue is that now a lot of work has to happen on your server(s), instead of in your users' browsers. The "perceived" performance issues is that, even if you have the server resources to easily handle all the additional http requests, you user now has to spend extra time waiting for latency incurred by those http round trips.
Both languages rely heavily on API's that were designed for different domains.
JavaScript was originally intended to run inside of a browser, so it makes heavy use of DOM API's as well as other in-browser operations such as AJAX. C# probably does not have good support for such API's as it was never intended to be executed directly inside a browser - although Silverlight may provide such operations since it is (in a way) a "C# Sandbox" inside of a browser.
On the other hand, C# is a general-purpose language that was designed to build basically any application, from server-side engines to client applications to services - you get the idea...
I have seen a C# project where javascript is embedded and can execute javascript within a C# code. Have a look here on CodeProject to see how that is achieved.
Technically, no.
You could even use Javascript server-side if you wanted (or client-side C# via different mechanisms).
They're really just two ways of getting the same job done.
I will soon begin the painful*(kidding)* process of migrating multiple, separate, Access Applications to "Real" applications*(notice the quotes, no flame wars please)*. Most likely this will be Web Apps as the usual reason is multiple users and deployability but I will take it case by case.
Some of these are traditional Access apps using Access as the back end and others are using SQL Server(a central one) as the back end.
What I am looking for is a combination of your experience doing this and what resources you used to help.
Websites, apps, standards, best practices, gotcha's, don't forget's, etcetera.
I am a 1 person C# shop with SQL Server back end so whether Web or not I will be looking that direction.
Also, is it overkill or unattainable to try and develop a Framework for this kind of thing? Would there just be TOO MANY variables to even try and walk this path? Anyone ever try this?
Some further info based on below questions. We currently have ~250 users and they are spread between 5 Locations.
What I meant by deployability is perhaps a little vague. I simply meant that we are a Non-Profit Organization and as such we do not have the best bandwidth available so deploying full apps, even through ClickOnce can be tricky when combinded with the highly fickle nature of my users*(I want that box purple, no green, no get rid of it altogether type stuff...)*.
My idea is to try and develop a "framework", of sorts, that will help to streamline the process of moving an Access App to a .Net App.
Now I fully understand that this "framework" may be nothing more than a set of steps and guidelines; like, Use ORM*(LINQ2SQL or SubSonic)*to generate DAL, Copy UI to corresponding UserControls, rewrite Business Logic.
I am just looking for your experience/expertise to help me streamline my streamlining process... ;)
Those apps which use an Access database to store tables and which need web access should first be upsized to SQL Server. There is a tool from the SQL Server group. SQL Server Migration Assistant for Access (SSMA Access)
Then consider moving to the web only that portion of the app that requires remote access. And leaving the rest of the app in Access. That could save a considerable amount of time.
Alternatively consider going to Terminal Server. That along with a VPN means just some software licensing costs and next to no work on your part.
That said what do you mean by "multiple users" and "deployability"? Possibly we can give you some suggestions there. Access is multi user out of the box. However if you have mission critical data or can't rekey the data in the event of a corruption or have more than 25-50 users on the LAN then you should be moving the data to SQL Server.
Now that it's public Access 2010 can deploy applications to the web. All kinds of very interesting stuff can be done. For more information check the Microsoft Access product group blog or my blog with the appropriate Access 2010 tags
Speaking from experience I think you would need to upgrade on a case by case basis. Upgrading is essentially a re-write from scratch and you should take the opportunity here to re-design as necessary. The type of application structure and code style used for Access (likely to be procedural I'm guessing) is very different to a well designed OO .Net app.
You will be able to re-use the SQL Server databases of course and, depending on the apps maybe even the Access ones. If you're feeling brave you could even try the upsizing wizard although I wouldn't recommend it as we found the results less than ideal.
I would also advise you take a look at some kind of ORM tool (we use Subsonic) as this can massively reduce the amount of boiler plate code you need to write. Some ORM tools will also generate DDL for your database too.
We follow these standards (good idea to pick a standard early on and stick to it we found) and also found this really useful to get up and running.
Hope this was some help.