I'm trying to make an application that will allow a user to initiate builds, see build info etc, and just general TFS based actions.
I've found a few guides on how to use the SDK... http://msdn.microsoft.com/en-us/library/bb286958.aspx
But I can't use the TeamFoundation.*.dll's in the metro/win8 app... http://msdn.microsoft.com/en-us/library/windows/apps/br230302(v=vs.110).aspx
so, is there an alternative? Do they have a separate api? (you can access a tfs project via the web access, providing a web based alternative from doing it all in visual studio).
Thanks,
james.
Windows RT is an ARM based surface and the TFS SDK/OM is only available compiled for x86. So, it will not work.
Windows Surface PRO available later will be x86 based.
The closest you could probably get is if you coded directly to the SOAP web service layer directly. The TFS team is also starting to create RESTful http APIs with light http clients but that's a work in progress that's just starting. That would be the long term approach available someday.
If you're creating a Windows store app, you should note that it's sandboxed. The TFS team is looking into that as we transition toward REST and a more modern REST client.
Related
I am developing a ASPNET web app which uses interop for different tasks. In order to make the app faster I was wondering if I can run Excel on the background while the view is loading. I tried the following approach:
enter image description here
However, every time you go into the view the app is initializated so you have the app running many times in the background. Is there a way of doing it?
Thanks!
Microsoft does not currently recommend, and does not support, Automation of Microsoft Office applications from any unattended, non-interactive client application or component (including ASP, ASP.NET, DCOM, and NT Services), because Office may exhibit unstable behavior and/or deadlock when Office is run in this environment.
If you are building a solution that runs in a server-side context, you should try to use components that have been made safe for unattended execution. Or, you should try to find alternatives that allow at least part of the code to run client-side. If you use an Office application from a server-side solution, the application will lack many of the necessary capabilities to run successfully. Additionally, you will be taking risks with the stability of your overall solution. Read more about that in the Considerations for server-side Automation of Office article.
As a workaround, you may consider using the Open XML SDK for open XML documents or third-party components designed for the server-side execution.
I have a strong background in .Net and some Python. After years of PC work, my primary (only) machine at home is a Mac.
I have an idea for an iOS (and Android) app that would be a total labor-of-love, there is basically no monetization possible with it, but I still want to do it. What is the most cost effective way to deploy an app, with Xamarin and only using a Mac?
I will need a database to power the app. I know that I can use MS Azure for a pretty low cost but I know that Xamarin licensing for the SQL Data library is a total budget killer. I know that I could expose web services, but that would require writing the web services with .NET and I want to do this project exclusively on a Mac.
So what are the database options? Can I hook Xamarin directly to MySQL? Can someone please provide sample code for connecting from Xamarin to MySQL? What are some of the better MySQL only providers? I wouldn't need a web host, just DB.
Are there any other potential costs/licenses that I'm overlooking?
You never want to expose your database directly to a mobile client. You always want to have some sort of service brokering your db requests to the outside world.
If your client is simple enough that it will fit under the app size limit, you can use Xamarin's free tier. Otherwise you can use the Indie tier. You should not need the business tier. If this is something that might be a workable open source project, I believe you might be able to ask Xamarin to donate a license.
You will also need an Apple developer license, $99/year, for deployment.
You can use MSSQL, Azure, MySQL, etc to power the server side db. You can write webservices with ASP.NET, PHP, Ruby, etc - there is no reason the server side has to be .NET unless that is what works best for you. You can run a VM on the Mac and run VS2013 Express for ASP.NET, or do it directly from the Mac with Xamarin Studio (not sure exactly what level of support there is for this under Mono, but it is doable). Most of the other options can be written natively in OS X.
Other than the Mac hardware, the only other absolute expense is $99 for the Apple Developer account.
For web services on a Mac with C#, look into v3 branch of ServiceStack. There is also ServiceStack.OrmLite which is a database client (MySQL, SQLite, SQL Server etc), it has a SQLite implementation which will run on the local machine (mobile) with Xamarin.iOS & Xamarin.Android.
I'm partway through development of a build wallboard that displays the last 20 automated builds undertaken by the build server, all looks well and good, and when a build has tests, i'm automatically recording the test results (to be used interactively later)
I love building instant messaging bots and since my new workplace uses Lync (2010) I have started building a bot interface, that works over that.
I have managed to get it to start a conversation with the people that requested the build, that's about as far as i've got so far - i'm hoping to allow the users to ask 'why?' and be responded to with build errors or which tests failed etc etc. Thanks for reading through the backstory!
The Question
Should I continue writing a bot on lync? It seems like a pretty cool platform and protocol, but it seems very proprietory, and locked in. Are there more open platforms I should aim for that may end up being supported by Microsoft's unified messaging doodah with lync2013.
Thank you for your time, I hope this question is specific enough.
If your organization has already invested in Lync and its infrastructure, it's hard to imagine them giving up on it unless it has major issues.
Of course there are other options, but it's not like Lync is going away anytime soon, and Lync 2013 recently came out so it is still being invested in by Microsoft. And there is a wealth of information/documentation/communitry (i.e. TechNet) around the Lync SDKs, so that is also a bonus.
Also, Lync is built on top of SIP and well-known media codecs, which are not proprietary. (their SDK is proprietary, of course)
I have a MVC4 application that runs on the cloud. I keep multiple backups but I would like also to have a backup some place online.
Does anyone have any suggestions as to where I could put this backup. In total the 3 projects I have occupy about 250MB. Could I store these somehow in an area of the cloud that I am already paying for. What about other places online?
Do you not use version control? If not, this would be the time to start.
Check out GitHub or Bitbucket. Both are free to use for public repositories, and have very affordable plans for private projects.
I would recommend Microsoft Team Foundation Server. TFS is integrated into Visual Studio.
Some of the key features
Up to 5 users free of charge
Unlimited number of projects
Continuous delivery to Azure (that can be very handy for you)
Work item tracking
Agile planning tools
Feedback management
VS Integrated Build (however, that feature is still in preview)
I've been using that service for several months and I would definitely recommend it.
I use dropbox for some of my backups, but there are plenty of alternatives, like Amazon S3, or hosting providers like RackSpace etc.
I also have a NAS box that I back up to. I installed SVN on it too, which I access via my laptop and my main desktop PC, so I pretty much always have at least 3 copies of the code at any one time. The SVN repository is also backed up to an external hard disk.
I don't use Azure (yet), so I don't know how their backup services work. I did find this link though, that might help you figure out if you can store your files separately.
I imagine, though, with it being hosted in a cloud based system, your code will be backed up and spread across quite a few servers - so it might not be that much of a problem for you.
We have the following three things we need to deploy to a Windows Server 2008 farm:
ASP.NET MVC 4 web applications (x3)
.NET Windows services (x2)
I have inherited the deploy process and would like to rewrite it.
Web Applications
When I am in Visual Studio 2012 I have a nice new publishing wizard for deploying web applications. Can this be used somehow? Or taken advantage of in anyway?
Windows Services
Windows Services are Windows Services, so deploying them to a Windows Server should be simple. Right?!
Then there is how to deal with the fact we are deploying to a farm of Windows Server 2008 machines, not just one.
Everyone I talk to seems to have to reinvent a new, custom and complex process that is difficult to maintain and not very malleable, often with custom XML files with all sorts of actions etc that are hand edited. Even psexec gets involved a lot - this smells wrong to me.
Given that at least for the service and the web applications we are doing nothing special whatsoever, what is the simplest way to have a nice, potentially VCS commitable publishing process.
Apologies if this is a ridiculous question, if so please help me understand why!
To be a question on here though, it needs to be answerable. So to summise: what is the easiest/an easy way to deploy web applications and windows services to a farm of Windows Server 2008 machines?
The modern way to do this would be to build your deployment on WinRS (remote power-shell) which uses WinRM for its communication and authentication. WinRM is a bit of a learning curve to configure if you want to step off the golden path though, as I've been finding recently :).
Almost all the configuration services you need (firewall=>netsh, Remote management=winrm, services=>sc, Windows features=>dism, Event Collection=>winecutil, gpupdate, etc) are available as command-line tools and often also directly supported in PowerShell, so you don't need to code anything to the APIs.