Beginner level question
Scenario: Have simple string cocantation tool, that I might expand later on. I'm interesting in keeping updates and "upgrades to it" as time progresses. They have access to the shared drive.
Share one executable and they just have shortcuts to it? Multiple users using it? (might have issues with personalization that I could setup later on.)
Have them copy over the setup file to their individual computer and install individually?
If applicable, please let me know HOW I could publish updates simply with the "publish tool." Is it fairly straightforward and updates them telling them updates are available?
I'm a beginner so a little help or links to beginner level explantions on this would help.
Look into ClickOnce.
I think that executing files on a shared/widely accessible drive is probably not the best idea. How many people are we talking about?
Since you only have 7-8 people in your group, maybe the best solution here is to simply make the setup executable available on your shared drive, that way your users can have access to the newest version of your tool whenever they like and can install it on their machine at their leisure.
sure there are more elegant solutions here, but they may take too much hassle to implement for such a small group, especially if you are not getting paid to distribute this tool to your peers.
Sometimes the simplest approach is best, and I don't usually condone manual efforts, but in this case it may work best for you.
Good luck,
-Robert
Related
Let me start by saying that I do not know whether this is the best stackexchange site to ask this. I am not directly asking for an opinion on which is best (although obviously it would be appreciated). I just simply need some guidance.
I am wanting to start on a hobby project but its going to be a big old thing so I wanted to start off small. I basically need to know how to stream a video of my desktop (or any desktop) into a WPF application. Future enhancements would include doing multiple displays from different computers on a network into a WPF application.
I have done some research and someone has given me a list of Libraries that I could use avlib, ffmpeg, gstreamer. So I started with the first two and could find ffmpeg however I found people stating that it is better to use libav. But I couldn't find any information on avlib really, is libav a successor to avlib and that is why I can't find it?
Finally all these articles that I were reading were from 2012 as well so I don't know whether there is an even more up to date version. The last release notes for libav were from May this year so my assumption is that this is still being developed.
Any guidance would be really useful as I am not sure where to start looking (even if it is telling me which site would be best to post this on).
For FFmpeg vs. Libav, see this post. Beyond what you'll read there and in the posts linked from there, this is entirely opinion-based. See also this, which is relatively fair although a bit old.
For FFmpeg/Libav vs. GStreamer, this really depends on what type of API you prefer and what special plugins you need that are only available in one or the other. Read docs for both, play with both and see which one suits your needs and/or preferences better.
At work, we are required to use a custom "source control" system. Basically, it takes snapshots of our code whenever we push new changes to our live environment. There are no rollback capabilities except to get a copy of the last live push, there are no mechanisms for seeing who changed what, and once one person is working on the code someone else can change the source and you would not know (unless you spotted the change).
I would like to implement Git in this environment but I'm not wise enough in the ways of Git to figure out how best to do this. Here are the requirements that I need to handle:
Source code is stored on a remote file path.
Once I start a project, anyone can change the remote source (I would like to capture these changes if possible).
The source is (usually) existing before I start to work on it.
After I complete a project, someone else may change the source (not using Git).
I am going to attempt to get the rest of my coworkers involved in doing this too.
I have only file read/write access to the remote server.
My coworkers do not like the command prompt (and, quite frankly, I prefer to use a GUI), so use of a GUI (like GitHub for Windows or, even better, the Team Explorer tools inside Visual Studio) would be a high priority.
We are a Windows-only shop specializing in C# and ASP.NET MVC so any solutions would need to work inside those bounds.
The impact on the remote files and folders should be minimal. I know Git is light but anything I can do to keep it as invisible as possible will be great.
I've looked into how to do this but I've not found a good solution that works for me (or at least that I understand would work for me). I found this article but it didn't appear to really work well for my environment (again, maybe that is my lack of understanding):
http://mattsnider.com/develop-locally-using-git-instead-of-your-company-s-crappy-version-control/
Any help that you can give would be much appreciated. I would really appreciate it if the help you give is doable for a Git user (me) who is not very knowledgeable. Steps to follow and instructions on why would be tremendous.
If your employer already has an established version control system that can handle all their different artefacts that the company needs to store (which will be more than just source code) then don't even try to actually change their system.
The question is more about how you can help yourself, which will depend on the level of access you have to personal storage and to network storage - the latter being maintained by others.
Assuming you have local storage, then you can set up a git repository within your own local copy of the source code. You would then set up a remote on a/your network drive to act as your back-up. (as described in the blog you reference).
I use (variously) Git-for-Windows, Git-Gui, gitk, and Git Extensions for my development so that I can pick and mix the best tool/command for any particular task. I find it especially useful for my Matlab development with its rapid interactive edit-fix-update common in (my sort of) systems engineering.
When I have a stable version in a commit, that I want to send back to the company VCS, I can then check it out/back-in (or whatever their process demands) to their system (do tag that commit).
Likewise if there is an update to another file that you need from their VCS you should have a branch for receiving it's checkout, followed by a merge back into your development branch (or whatever flow most suits you).
Regularly push your local repo onto your bare network repo so you have a backup and some security. You can always bundle your repo, or archive a commit as required for other backups if you need.
I am using tortoise SVN with Ankh. I really have spent too much time tweaking and cleaning mess from time to time and I lost hope in educating each every developer on how to use things properly. I am sorry but I am fed up and tired restoring the repository/reverting/fixing merges manually, sometimes even having to write some code again.
So here's my question : Is there a chimpanzee-friendly solution for source control privileging Simplicity over Flexibility ? Projects and teams are small and I figured out that we just need VERY simple and basic chekout/checkin mechanisms, with no flourish, and limited functionality and features. That would help me stop being paranoid about projects integrity.
I know that there is no easy way to do this and there is minimum techinicity and discipline required, but I ended up wondering if we Really needed all that in our case, as in the long run, it causes more trouble than it helps.
Your problem sounds like it has more to do with process and branching strategies than anything else.
If your developers know to always get the latest code before checking in and resolving conflicts locally, running all tests etc, you will already have a leg up.
Educate your developers instead of trying to use a dumbed down SCM (that in the future will probably not be adequate to your needs).
As for branching strategy - I had found that branch per feature is the most natural way to work and mostly avoids merge conflicts.
Changing SCMs will not help with your issues if you don't tackle process and branching.
First, I would suggest that you force developers to clean up their own messes, not do it for them. By doing it for them, you are only encouraging them to stay ignorant. By all mean, be a resource and provide help for them, but make them do it themselves. They will quickly learn what they have to.
Second, there are few options that have the kind of integration with VS that most developers would like. SVN is one of them. Team System is another (but a much more expensive and complciated solution). Visual Source Safe is also an option, but it's really an old, out of date system that hasn't been updated since 2005 (and even that, that was largely a patch job to a system that hadn't been updated in 7 years before it).
If you want free, there is nothing worth using that is simpler than Subversion. Everything else will be ancient technology (like CVS) that will have even more problems. There are several free SCM's that are more powerful, like git and Mercurial, but you would have even more problems. If you're willing to pay, then many third party tools have better merge and visualization tools. One I like is AccuRev.
There are also some better commercial SVN plug-ins for visual studio that may help as well. I've not used any of them, but they may improve the developers use of SVN.
Try the combination of Mercurial and Tortoisehg as GUI.
You can also use it from Visual Studio with VisualHG.
Every developer is free to clone and manage her own repository.
Once you reach an agreement you can push up to a colleague's repository or a central location.
To aid with adoption, you might convince others to watch the DVCS video on the FogCreek Kiln page.
See what-makes-merging-in-dvcs-easy and similar SO discussions regarding the relative ease of merging.
I would say that every developer that works in a team should have a strong understanding of source control principles. Maybe you should get better developers! :-)
To answer your question I have always found Team System wonderful and very flexible. With such good IDE integration, it can be configured to ensure best practice in source control. However, it is quite a big source control system so may be over the top for your purposes.
I believe the issues is more of process than product.
Strict written documentation and process might work
Keep it as simple as possible.
You might make adherence to the process a contractual obligation.
That said I have had very good luck with Visual SVN for Visual Studio.
It is easy to use and integrates well.
If that is too hard, might revert to TortoiseSVN which is pretty idiot proof.
As for an alternate super simple product I know not of such a product, but
if you really need something lightweight, then datestamped and named zip
files is a the poor and ignorants form of source control. Merging and
restoring is a bitch though.
We have an in house winform application that is used by about 20 users in my company. It's a real pain having to send the users a new msi when the application has changed in scope and I would like to have the users prompted from the application as to whether they would like to update their copy. My thoughts are that the source of the application would be on our company server and that the application would look to a database to see if updates area available. Aside from that I don't know where to go from there. Has any one done anything similar to this or does any one have any recommendations on how I should implement this.
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.
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)
ClickOnce.
If it's a fairly simple program (not many dependencies) consider keeping the program on a network share have have users run from there.
The most popular solutions with graphical update prompts are AutoUpdater.NET and WinSparkle. For a more powerful solution, take a look at Google Omaha.
Squirrel is definitely worth a look
In a .NET C# program, is it easy to transition from FTP to SFTP? I'm trying to get a sense of how muh time it would take the contractor to make the transition. My personal experience is mostly with PHP, so I have no idea.
Basically, what I'm talking about, what steps would have to be made? Obviously, different commands, but would anything else in the code itself? Like do the commands require different formats, etc.?
Also, if anyone has a list of all the .NET/C# FTP and SFTP commands, that would be really helpful.
Clarification, as requested: The program is uploading extremely small files (20 KB) to a server. By format, I mean visually, because I was wondering about a find/replace job.
This is a pretty vague question. You haven't told us what the C# program is doing with FTP. Is it a server, is it a client, is it doing directory listings, is it uploading 100 GB files? What library is it using?
According to this forum post , there is no built-in support for SFTP in .NET, so you would have to use third-party libraries such as SharpSSH or Granados SSH.
I don't really know what you mean, "do the commands require different formats". Obviously, the code will use different:
Libraries
Types
Wire protocol.
It will obviously appear somewhat similar, thanks to the abstraction of the libraries. I suggest you provide more information, and a clearer question.
One thing that you'd need to consider is how well your current code is written. If your existing FTP implementation is horribly designed spaghetti code then converting it to SFTP may be next to impossible and take way longer than you'd like. Without knowing the current state of the code, it would be difficult for anyone to make a good estimation. And even if you do get an estimation from people on this site, I wouldn't recommend trusting it (even though the people on this site are great) since without all the information in front of them it will be next to impossible for anyone to come up with a reliable estimate.
Perhaps you should consider hiring a good consultant or business analyst to do a thorough estimate for you.
It really depends on what C# library your developer has used to implement FTP.
If, for example, they used edtFTPnet, a widely available open source library, then the upgrade path is trivial if you replace it with edtFTPnet/PRO. The PRO version has the identical API and just a few extra lines of code would be needed.
I've been down this road.
It depends, but keep in mind that SFTP, FTP-SSL and FTP are different.
If he's writing the SFTP libraries himself, a month or two, since it's a lot of work to make it perfect and compatible. But he should NOT do that.
In short, get him to use an external library to add SFTP functionality. This will make it pretty short. Maybe a week or two of full-time work, but it depends on how involved it is. There's open-source options.. But for $50-150 you can get a license to well-maintained code that's really easy to use. will save him days of work.
There's links above, but I'd look at:
Free:
http://www.enterprisedt.com/products/edtftpnet/overview.html
Commercial:
http://www.weonlydo.com/