Friends,
I know there are lots of similar topics, but I'm creating this thread to take expert suggestions/guidance regarding my project for a non-profit NGO website. I'm a volunteer for rotary International and They need a utility which can be used to send their newsletter.
I'm not aware of the kind of email database they have, let's assume
.xls file with three columns (to, cc, bcc), maybe 1000s of data,
No database is available in their hosting plans, and I can't make
them spend now.
Most probably a msword (.doc) file would be available with some heavy
images as newsletter.
They have google apps ID
So what I'm seeking is: A way which is Right, shortest, quick, and easy to understand.
Lot of code is available on the internet but the right way to do things comes only with experience. So plz suggest me what do u say about this?
Standalone/Desktop, or web based? A WinForm application, or ASP.NET?
Desktop application may hang/crash due to 1000s of mail requests on google. Web application may force them to share their email database on ftp and then I will need to create another way to subscribe & unsubscribe online.
Plz help me start...
Personally I'd use (and do use) an integrated mailing system such as MailChimp
Why re-invent the wheel right? Services like this allow for uploading data from many types of storage, they manage your suscriptions and provide an easy method for users to unsubscribe.
You've suggested in your comment on Jamie's answer that you're worried about there being "nobody to take care of it after development" - but who's going to take care of whatever code you write? At least a system like MailChimp has documentation and is understood by a small but accessible group of people: code you write will only be understood by you, and won't be maintainable or extensible.
As with any project, there is no "right." There are simply tradeoffs. You've talked about automation of thousands of emails, subscribing and unsubscribing, and basing the email on a Word document. That's a lot of functionality to ask for help with on a simple Q&A site.
You say "Desktop application may hang/crash" - but that's equally true of a web application, you just won't see the hang. The trick would be to code your application in a way that doesn't hang.
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.
A friend likes to limit his applications to a use a certain bandwidth-limit. Seen as he doesn't have the widest connection and - for example - not every application that downloads/uploads has the ability to throttle/limit their downloads/uploads (Like Steam or a torrent downloader.). So he was wondering if I could maybe put something together since I fiddle around with WinForms often. I recommended NetLimiter and NetBalancer, but I was curious as to whether I could make this in C# myself.
I have searched the web and found some decent solutions as to throttling in an application itself but as to throttling applications outside of the current application you have the source code of, I haven't been able to find anything that would help me understand how to program this from scratch.
Do any of you know how I'd go about throttling other applications? Would I have to write my own network interface and have Windows reroute traffic through that?
Thank you for your time.
EDIT: Seen as the first comment tells me I'm at the wrong address with C#, I rephrased my question in the hopes of a better way to get an answer.
I have a company that needs a document management system.
I have looked at SharePoint but it has far to many bells and whistles. The company wants something that doesn't have intranet portals, app downloads and all the other waffle (they simple don't have the skill nor the inclination to spend thousands learning it).
I am finding that SharePoint is a little like a fork-lift bus truck car. It trying to be everything to everybody which usually ends up useless to all.
My question is does SharePoint Foundation work out of the box as a document management system or is it like an engine you put your own code upon.
The more I read through Google the more conflicting information I come across without any clear definitions.
What I want to end up with is a document management system that has authentication and a simple page / screen / whatever to link / admin to those documents.
As per usual Ill probably end up having to write my own but it would be nice to not keep re-inventing the wheel.
SharePoint definitely has a learning curve, there's no getting away from that. However you don't need to set up all the "bells and whistles" if you just want a basic DMS.
To answer your question, you don't need your own code to get a SharePoint site up and running. You will however need to spend quite a lot of time figuring out what configuration you need for your needs.
We're using SharePoint 2010 Foundation as a simple document repository in a couple of web apps and it works fine. No Wikis, no versioning, no custom pages. That stuff is availablem but we don't need it so we don't enable it. The nice thing about it is the security which hooks into AD so authentication can be set up easily and it is robust. Our DMS solutions are accessed via the internet by users, and internally by apps, and SharePoint can handle that fine by setting up alternate access mapping so that you can get to documents via internal and external URLs.
I won't lie; I've spend a lot of long days cursing SharePoint, but it's still a far better solution than what I could have come up with myself.
In case your wondering, we're using 2010 rather than 2013 because we had been using WSS 3.0 up until this year and you can't upgrade directly from WSS to 2013. But since we only need the basics, doing a second upgrade to 2013 wasn't worth the effort.
The truth is Sharepoint can be used as a sort of document management system (ish). But in truth it is far to over complicated and has gone rather off at a tangent from the demos I was original given when it first came about in the beginning. Alfresco an Nuxio are probably much better. (but even they have their issues). You simple have to look at all three and make your own decisions as now I know this is not a simple question. I personally went for Alfresco but for very exact reasons, even it has some issues but generally speaking it is the best(ish) out of the three. (Nuxio would of been best except for its 'purchase your admin interface' model.
This may have already been asked before but I did not see it anywhere.
Essentially, what I'm looking to do is to have a small C# app (EDIT: or BHO) run and detect when IE (8 or higher) has been launched by a user. Once it has launched, it needs to just sit there until it notices that an authentication challenge popup has been presented from within IE. It would then hide the IE popup and present the user with a custom authentication popup. This new popup would then pass the entered credentials back to IE for authentication.
The app (or service) would cache the credentials and pass them to any further authentication popups received on a local Intranet. So, this is a sort of custom quasi single sign-on solution.
Before people start suggesting changing settings in IE or on the server(s), please know that this is not possible. The above explanation is exactly what we need to do. I don't like it either.
We currently have a small in-house utility written in C++ (not .NET) that handles this exact identical behavior very successfully, but the source code is no longer available for fixes/upgrades.
Anything would be helpful. Thanks all!
FYI - Just saw the first comment. No, this is not a type of malware, pwd spoofer, or similar. The employee gets a customized, company-logo'd credential pop-up to handle everything. The purpose of it is to handle multiple different types of authentications (some are custom) specific to the varying sites within our Intranet.
I finally found and decided upon a solution that is already working as a prototype (very limited prototype). There's still much work to be done, but at least there is light at the end of the tunnel. If I head a different route or receive better suggestions, I'll be sure to update this information. For those whom might ever need something similar (doubtful), here's essentially what I'm doing.
Browser Helper Object
Instantiated with each new IE instance.
Registers with IE to receive events and new windows/controls being created.
Hooks to receive descriptions of controls for logic to decide what to do.
Handles to each authentication dialog windows or control.
Handle to UIAutomation COM to inspect requesting server and realm.
Multi-threaded support capable of thread blocking.
Encrypted credentials cached in memory.
.... and a whole lot more.
I hope that helps anyone needing to do the same. Thanks all for any assistance you could give. I guess everyone is as much of a noob with BHO's as I am.
EDIT 2/14: This is indeed the answer. I have the BHO working as desired. There is still some very minor tweaking to accomplish. (Actually, it's not that minor but it's working.)
Honestly this concept is dangerous. You are side-stepping the security model of the operating system to accomidate lazy users.
The other problem is that your architecture is fragmented. If you have tonnes of workstations across a big organization that don't use a proper platform for unified authentication (Such as AD / LDAP / Etc...) then you're going to run into a very-hard to maintain mess.
What you're doing here is plugging a hole, you're not fixing the crack. I strongly suggest you use this lack of source-code to keep "patching" the system together as the catalyst for change.
If you're so hell-bent on keeping the infrastructure as-is, then you should look to tested & proven software solutions to help aid in keeping things sane for your users.
Take a look at a FOSS Application KeePass. It will allow you to store your passwords securely (a problem your proposal would have to address anyway) and you can have your users store thier DB on a USB-Stick they keep with themselves at all times. They can log in once to thier KeePass DB and use the Auto-Type hotkeys to enter thier passwords in the various login boxes they are prompted for. This can work for more than just IE authentication requests, it can do all your applications.
The nice part about this is you can get people to use relatively strong passwords as they'll only have to remember the one (KeePass DB).
Ultimately you're going to run into issues trying to catch Authorization Challenges, even your existing solution is probably doing it in a very hack-ish way and you're going to find it increasingly hard in the future to continue this behaviour. This is mainly because it's an "IFFY AT BEST" solution, and will likely be made harder to execute as security matures.
I have two C# programs and I want to send some data back and forth between them. (And check if the data arrived to the other application.)
The two programs will always run on the same computer, so no networking capability is required. I've already read some questions with similar topics here, but I'm not entirely sure which is the right method for me. (WCF, Remoting, etc.)
What I want to know, is which one is the easier to implement for a beginner in C#?
(I don't want it to get too complicated anyway, it's only a few integers and some text that I want to send.)
If there isn't a real difference in difficulty, what advantages does one have over the other?
I'd really appreciate some simple example code as well.
Thanks in advance.
You can use Pipes to send data between different instances of your application. If you just need to tell the other instance that something has happened you can send messages from one application to another by using SendMessage api.
WCF essentially packages up the various methods of communication between applications (web services, remoting, MSMQ etc) in a single package, so that they are programmatically the same in the way that they are used, and the detail of what method is used is left for configuration of the binding between. A slight simplification perhaps, but essentially what it's about.
It is worth getting into WCF if you need inter-process communication, and this would certainly be my advice as to the way to go with this. It's worth looking at IDesign, who produce a number of articles on the subject, as well as some reusable code libraries, that you may find useful. Their Juval Lowy has also written an excellent book on the subject,
Another good point about WCF is that if your requirements ever change and all of a sudden you have to move one of the application to a different machine, requiring now network capability, you will only need to change configuration on both sides, instead of having to recode.
Plus, ad David said, WCF is a good tool to have in your bag.
Cheers, Wagner.
I found MSMQ is simple to implement.