I'm trying to evaluate SharePoint 2010. I've bought the book "SharePoint 2010 as a Development Platform" from Apress to help me get started with SharePoint (I have C# and ASP.net knowledge)
In the first pages I saw this warning:
'We strongly recommend setting up a virtual server on a physical machine, such as Hyper-V or VMware on Windows Server 2008. [...] SharePoint projects occasionally crash the server during heavy development. Re-creating a virtual machine is much easier than losing your whole personal computer'
which begs the question: How dangerous / risky is SharePoint development? How can I crash the whole server with it?
I have never had to rebuild a machine because of SharePoint. BUT, I can understand the book's claim. The scenario I see is that SharePoint starts acting unexplainably bizarre, and there is no logical course of action to fix it. For example you try everything you can think of, and for some reason everyone gets a 404 to the site, even administrators. If you dig hard enough you find it was because a .resx file wasn't copied during a deployment or something. If you don't dig hard enough, you will be tempted to rebuild the entire machine for the reason of "something happened with permissions probably".
For this reason, I do keep my SharePoint environments in a virtual machine. It comes down to the fact that SharePoint can stop working and it's too difficult to figure out why. If I could enumerate the concrete reasons for this, I would say:
SharePoint's error handling is so bad and misleading.
SharePoint is influenced by every nook & cranny of the system, for example obscure group policy settings, regional settings, etc.
SharePoint is driven largely by "best practices" mentality, and has its own way of doing everything. Some things are still controlled by IIS settings, other settings must be done through SharePoint administration. If you do it wrong, you will just get crazy behavior, not a hint in the right direction. Because SP is so configuration-focused, juggling all these configuration settings is overwhelming. [edit] In other words, SP configuration is not intuitive. Getting SP to do what you want is a matter of following some official recommended practice, not following intuition. In an industry that only thrives because of developers' ability to adapt, improvise, and learn-as-you-go, SP feels more like system administration than software engineering.
Doing things in SharePoint like configuring / deploying can often take a LOT of time, and this can seriously interrupt the problem-solving flow. The amount of time it takes to just haphazardly try something can prevent me from trying things, and cause disorganization in my thought process.
Installing and configuring SharePoint is quite a task. So if anything goes wrong with SharePoint it will take long to reinstall it from scratch. But if you are using Virtual Machine you can install and configure a VM and take its backup. Now when anything goes wrong with your working VM simply delete it and create a new one by copying files from backup of your fresh installation.
Also depends on whether you want to do other things on your dev machine. I do pure .NET development on my dev machine and when I'm doing SharePoint dev I spin up a virtual machine.
SharePoint uses loads of resources and can easily slow a server right down. It can become a pain always having to stop all the services.
Related
I've searched for solutions for this question everywhere. They all say it's not possible. I know MVC is hosted server-side so Process.Start will affect the server and not the client.
Is there anyway I can still configure the site or the client or the servers to open a desktopprogram or file on the client when the user clicks a button?
Thanks!
Well, out of the blue, it rather hard for YOU to decide to run software on MY computer, right?
I mean, I might want to go view some cute cat pictures on your web site. However, while I am doing that, I doubt that security settings will THEN let you launch my banking applcation. Or how about you go rummage around on my computer, and grab files called passwords, or how about some files called banking information.
As you can see, the idea that since I decide to visit YOUR web site, you NOW going to start launching and running software on my computer? If this was easy, or even possible, then no sane person would EVER use the internet, since then you could at at will run software on my computer - such a possibility would make the internet oh so dangerous to use, and in fact so much so, that no one with a functional brain would ever risk using the internet again, would they?
So, as long as you are 100% clear that you searching for a way to launch and run software on my computer - such as accounting systems, banking systems, and that I would be insane enough to adopt a browser setup in which YOU can run any old software on MY computer?
No problem at all - but you want to at least be trained from the school of abused farm animals as to what you asking for here.
Note that you might be able to convince the users of that web site to eliminate or turn off any browser security, but then all of those users would indeed have a very vulnerable setup, and the resulting security issues would no doubt be deemed un-acceptable to any IT department.
I was learning more about ASP.NET MVC, and I decided to to take a course on Udemy taught by Mosh Hamedani, and this course involved me making an application called Vidley. I was able to complete the course entirely, however I came across a problem:
A day or two after I completed the course. My computer caught a virus and I had to reformat the operating system and reinstall everything. I had the application backed up on bit bucket, but the application just doesn't work with the database. When ever I try to create a new user, the application just throws an error. What do I need to do to get the application working with the database again. I tried looking at other topics but I couldn't see anything that covered my specific issue. I am thinking if there is any kind of configuration I need to fix with the database, but I am not entirely sure and I am concerned I will break the code.
It really is upsetting because I was going to add that project to my portfolio, so I could find a job easier. I am wondering what I have to do to get this web application to work with the database again, and where should I deploy it. Should I use a website like app harbor, or is there any other better platform. I am really new at this so I am sorry if I am asking an absurd question.
Please recheck your connection string as you have reinstalled everything even the operating system.
Check your Database server instance is running or not. If not, start that service.
Recheck database name, username and password in your connection string.
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 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.
I have a three-tier application which is installed in corporate environments. With every server version update, all clients have to be updated, too. Currently, I provide an MSI package which is automatically deployed via Active Directory, however my customers (mostly with 20-300 users each) seem to hate the MSI solution because it is
Complicated to get it running (little Active Directory knowledge);
The update process can't be triggered by the server, when a new version is detected;
Customers can't install multiple versions of the client (e.g. 2.3 and 2.4) at the same time to speak to different servers;
The update process itself doesn't always work as expected (sometimes very strange behaviour healing itself after a few hours)
I've now made a few experiments with ClickOnce, but that way to unflexible for me and too hard to integrate in my automated build process. Also, it produces cryptic error messages which would surely confuse my customers.
I would have no problems to write the update logic myself, but there the problem is that the users running to self-updating applications have too restricted rights to perform an update. I've found that they are able to write to their Local Application Data directory, but I don't think this would be the typical place to install application files into.
Do you know a way to an update that "just works"?
You can somewhat replicate what ClickOnce does, just adjust it for your needs.
Create a lightweight executable that checks a network/web location for updates.
If there are updates, it copies them locally and replaces the "real" application files.
It runs the "real" application.
The location for the application files should be determined by permissions and operating system. If users only have write permission to a limited set of folders, then you don't have a choice but use one of these folders. Another option is provide an initial installation package that installs the lightweight executable and grants r/w permission on a specific folder such as "C:\Program Files\MyApp". This approach usually requires a buy-in from IT.
I hope this helps.
It is really hard to provide you exact answers because critical information about the client side installer is not explicit. Do you install client side files into Program Files? Then you may meet problems when users are restricted.
You don't think Local Application Data is a folder to deploy application, but Google does. Its Chrome browser installs that way on Windows, and its automatic update process is even unnoticable (which may sound horrible). So why not deploy your application into this folder for restricted users? You may find more about Chrome installer here,
http://robmensching.com/blog/archive/2008/09/04/Dissecting-the-Google-Chrome-setup.aspx
Here's an open-source solution I wrote to address specific needs we had for WinForms and WPF apps. The general idea is to have the greatest flexibility, at the lowest overhead possible. It should give you all the flexibility you need for all that you have described.
So, integration is super-easy, and the library does pretty much everything for you, including synchronizing operations. It is also highly flexible, and lets you determine what tasks to execute and on what conditions - you make the rules (or use some that are there already). Last by not least is the support for any updates source (web, BitTorrent, etc) and any feed format - whatever is not implemented you can just write for yourself.
Cold updates (requiring an application restart) is also supported, and done automatically unless "hot-swap" is specified for the task.
This boild down to one DLL, less than 70kb in size.
More details at http://www.code972.com/blog/2010/08/nappupdate-application-auto-update-framework-for-dotnet/
Code is at http://github.com/synhershko/NAppUpdate (Licensed under the Apache 2.0 license)
I plan on extending it more when I'll get some more time, but honestly you should be able to quickly enhance it yourself for whatever it currently doesn't support.
If you don't want to give your users too many rights, it is possible to write a Windows Service, which will run on each computer under an account with the appropriate privileges, and which can update your application, when a new version gets available.