We have a multi-staged development environment, comprising Development, UAT and Production systems.
When developing solutions that will be migrated across all environments, we would like to be able to take advantage of all of the available development tools, including the SharePoint UI, SharePoint Designer and Visual Studio.
My question is, are the tools mutually exclusive?
Is it possible to create some components like Lists and Views using the UI and Designer, and then use visual Studio to create more complex features like web parts?
If so is there a specific process that you need to follow to make sure all of the tools play with each other for your solution?
In my experience... if it's possible to do in the UI, do it there. If it's not possible to do in the UI, but it can be done in Designer, do it there. If it's not possible in either the UI or Designer, then and only then, should it be done in Visual Studio.
If so is there a specific process that you need to follow to make sure all of the tools play with each other for your solution?
this is a important, but not easy to answer. For instance, I developed a custom web part that stored info in a list. At any point, a site owner could modify or delete the list from the UI and my web part would fail... to this day that's the way it is. It's a classic content management system conundrum, allow users to do their job while prohibiting them from breaking stuff. good luck!
Related
I'm working for a company which maintain several Desktop application projects written in C++. All of these apps have complex GUI interfaces. What I mean by "complex" is, among others, interfaces with many components, deep component hierarchy, usage of frames, third party and/or custom component packages which support features like transparency and animation.
Until now we always used the Embarcadero RAD Studio suite to write and maintain our apps. However the many recurring bugs of each new version has tired my superiors, and now they are considering the possibility to migrate to Visual Studio.
I think that migrate the application core functions written in c++ will not be a real issue.
However for the GUI it's an other story. I had a previous experience with complex interfaces under the Visual Studio 2003 compiler, and I remember that this was a painful work to create and maintain them. There was no real designer, components were limited, and a huge part of the job was to be done manually. From that I took a look on the designing tools provided with Visual Studio 2017, and my first impression is that not much has changed since. The designer for c++ projects is still so rudimentary, especially in comparison to the RAD Studio VCL, with its well-supplied component library. The C# API is closer than what I need, but I cannot envisage to rewrite all my code in C# as a serious option.
I tried to search tutorials about the good practices to apply in a such situation, but until now I found no helpful info.
My questions are:
Can I recover my current GUI interface, at least a part of it, while I migrate to Visual Studio, or do I have to plan to rewrite everything from scratch?
Does Visual Studio provide a mechanism similar to VCL for composing GUI interfaces, installing third parties packages and writing custom components? And if yes, where can I find relevant info about that?
Is a such port possible without a high dose of headache and tears? Where can I found relevant info about a such process?
I am also currently working on a product which is developed using Embarcadero RAD Studio and some 3rd party UI controls. Development was done many years back, so its UI is quite older style. I tried to migrate it in Visual Studio, by developing application logic in C++ and UI in C#(WPF). But it is as good as writing new application, cost is more. So we discontinued that exercise. However what I learned during this is –
Migrating VCL application from RAD Studio to Visual Studio is like writing new application. There is no one-to-one mapping(data types, stuctures, UI controls etc), you have start from scratch. Also there are no tools available which can help this migration.
Some data types, data structures, UI controls are easily available in RAD Studio, which are not available in Visual C++ (MFC), and vice versa. So you have to review every code line while migrating the application logic.
There are no 3rd party UI controls available for Visual C++(MFC) which can make your life easy. For RAD Studio you have LMD tools, businessSkinForms etc.
After working on RAD Studio over 5+ years, Developing UI is quite easy in RAD Studio (UI in C++). However in Visual Studio you can develop your UI in C#(WPF) which will be rich and can communicate with application logic written in C++.
As you said, you have several desktop applications developed with RAD Studio, while migrating to Visual Studio start with smaller and standalone application. So you will get some confidence during migration of this application and then you can put such migrated small application in production one by one without impact.
~Nilesh
Visual studio 2013 has its own accessibility validation, to check the accessibility one has to click on the tools menu, then click Check Accessibility, my question is: it is possible to make this validation automatically with MSbuild or with another tool?
Thanks
I need to check websites (MVC projects)
You may also want to look at tenon.io (http://tenon.io/), they have an extension for VS2013.
Tenon differentiates from all the other tools by providing an API which can be leveraged to integrate automated testing in to the development process.
Karl Groves says it better than I could:
All of my projects use Grunt, ... Tenon automatically performs unit testing on its own code. When something goes wrong, Grunt stops and yells at you. You can even tie Grunt to pre-commit hooks. In such a workflow nothing goes live without all your Grunt tasks running successfully.
Imagine, an enterprise-wide tool that can be used in each phase, that works directly as part of your existing workflows and toolsets. Imagine tying such a tool to everything from the very lowest level tasks all the way through to the build and release cycles and publication of content. That’s why I created Tenon.
While Tenon has a web GUI, the web GUI is actually a client application of the real Tenon product. In fact, internally Asa and I refer to and manage Tenon as a series of different things: Tenon Admin, Tenon UI, and Tenon (the API). The real deal, the guts, the muscle of the whole thing is the Tenon API which allows direct command line access to testing your code.
The beauty of Tenon is that because it is essentially an API, it can plug in to anything, Sublime, Webstorm, Netbeans, Notepad (probably not), Visual Studio!
Tenon.io Visual Studio add-on, compatible with 2013/2015 and 2013 Community Edition
http://blogs.msdn.com/b/visualstudio/archive/2015/03/03/improving-html-accessibility-with-visual-studio-extensions.aspx
The only catch, it’s not free for corporate users and it’s in the cloud (unless you pay Enterprise pricing for a local install). Pricing info: http://www.tenon.io/pricing.php
Karl Groves writes about his motivation for creating Tenon: http://www.karlgroves.com/2014/03/13/everything-you-know-about-accessibility-testing-is-wrong-part-4/
I think you need the AccChecker Console
https://msdn.microsoft.com/en-us/library/windows/desktop/jj191809(v=vs.85).aspx
If you want API access to this you should read AccChecker API
https://msdn.microsoft.com/en-us/library/windows/desktop/jj191808(v=vs.85).aspx
Overview here:
UI Accessibility Checker
https://msdn.microsoft.com/en-us/library/windows/desktop/hh920985(v=vs.85).aspx
The closer solution I have found so far regarding this topic is in Visual Studio 2015 by adding the Web Accessibility Checker extension from Mads Kristensen, which is also free. The extension can be found at the Visual Studio Marketplace website. You can see the usage instructions within the description of the extension. This is an example of what you get once build the solution and tap on the Error List panel:
I hope can help.
We are implementing Team Foundation Server for a better alternative over Microsoft Office for Work Item Tracking, Requirements gathering, etc. I am thrilled to have our team implement this, as I have used it in many of my past projects. That said, we are having some logistical problems implementing the solution.
One of my team members is a blind developer. He can successfully develop using SQL Developer, Eclipse and other programming software. However, we are having difficulty figuring out the Team Foundation Server interface using JAWs and pure keyboard access.
We originally tried to use the Visual Studio Online interface, which proved to be completely inaccessible. He installed the Team Foundation Server client, which seems to be significantly more accessible, but it is still difficult to navigate, especially with multiple panes of information and navigating between the sections of functionality.
We searched online for keyboard shortcut charts, accessibility, etc. and have found a few resources. However, none of them have solved the problem yet. Do any of you have any suggestions for how to make it more accessible? Is there a keyboard shortcut scheme for accessibility that we can interface? Have you found any good resources online for accessibility shortcuts with Visual Studio Team Foundation Server clients?
Thank you for your help. We are up for any solution, whether it be a Team Foundation Explorer Everywhere plugin, standalone clients, etc.
We do have keyboard shortcuts for the clients. For Team Explorer (standalone or VS), you can find the list at http://visualstudioshortcuts.com/2013/. We also do accessibility testing for TE/VS, including with JAWS. I watched a video in October that one of the teams had put together to show improvements that they had made. The before was pretty bad and the after was significantly better (and doing the work was motivated by another team at Microsoft who pointed out the shortcomings in trying to use it). The changes went into Update 4 of VS 2013. That's going to provide the best experience we have available. Please give that a try, and let me know what you think.
[Update] Also, we have a handful of key bugs in the web UI that we are working on that in the next month or so will improve the web UI experience in VSO and TFS 2015.
[Update] Here's a list of the current shortcuts, which includes both the web UI and Team Explorer.
Just wanted to post this for others researching this issue. I am a blind programmer who uses the jaws for windows version 17 screen reader. The corporation I work for just installed team foundation server 2015 for teams to use as a scrum project management tool.
The web interface is not useable by me. While some of it is accessible, meaning some links and web page elements are spoken to me and can be clicked, it is not useable in a practical sense. The entire web interface is a drag and drop interface that requires the use of a mouse and does not have any keyboard support to drag and drop items. For example, dragging PBI's into a feature or sprint is not supported by the keyboard or web page elements like html buttons you could click to move PBI's from the back log, to a sprint, to in progress, to completed, etc.
In aiddition, the tree control used is not accessible and is used for quite a bit of web page tasks. I think the tree control used is probably a jquery or javascript item.
The visual studio 2015 team viewer option is somewhat accessible, but it does not appear to allow you to perform all the tasks that the web interface does perform. For example, creating features, creating sprints, moving PBI's into a sprint, etc. If those options are present, and are accessible, I cannot find easily how to do it using the vs 2015 team viewer client.
Overall, while some of the features in the vs 2015 client and also in the web interface are spoken, tfs 2015 is not useable in a practical sense and does not allow a blind programmer to be as fluent as a sighted person using the tfs system. So at this point, I am not able to use the tfs system and must rely on sighted team members to key in my PBI's and drag / drop and create sprints for me. Very disappointing.
We're looking into migrating to TFS 2010 in the next few weeks. However, we're unclear on what kind of tools are required for the team. We know developers need Visual Studio but what tooling is required for Project Managers and Testers that will ONLY need to manage work items? Do they also need Visual Studio to just view and edit work items?
Project Managers and Testers can use the following methods to access TFS 2010
The web access portal - this allows the ability to create/run queries of work items, and even view source/builds if they want
Excel/Project - Both have integrate with TFS. You are able to load work items directly into Excel/Project, edit them, and publish them back to TFS.
Visual Studio with Team Explorer only - This is a barebones installation of VS, with the Team Explorer only. It doesn't take all that long to install, but it will say "Visual Studio" when launched. Not sure if that is scary to testers/project managers.
Web access provides a good complete set of functionality, but having VS/Team Explorer will provide a rich client experience (read: faster, more responsive).
Additionally, in order to get the Excel/Project integration, you'll need at least the VS/Team Explorer installed on the client box, even if they never use VS. And you need a CAL (Client Access License) to use the web access portal.
So to summarize, TFS provides a lot of ways for the non-developer to interact with the system, but all of them require a CAL, and most of them require installing VS/Team Explorer on the client machine.
In short, they don't need Visual Studio. They can use Team System Web Access (formerly known as TFS Web Access) to do pretty much everything a developer can do, except associate a check-in with a work item. After you install TFS 2010, you simply browse to http://yourserver:8080/Tfs/web and you're in!
Project Managers (and all other team members) can also work with work items from Outlook using 3rd party TFS client embedded in Outlook: TeamCompanion www.teamcompanion.com. This way, assuming they otherwise use Outlook, they wouldn't need to change tools or use any additional tools at all.
As is the case with Excel or Project integration they would still need a TFS CAL and additionally a TeamCompanion license.
TeamCompanion supports much more than just work item management: Email/TFS integration, SQL Server Reports, SharePoint document integration and much more...
Full Disclosure: I am the Product Owner of TeamCompanon, so I may be biased :-).
There is a web front end which you can use to manage the work items. There is also integration to Excel and MS Project.
See http://msdn.microsoft.com/en-us/library/ms181304.aspx for more information on Team Foundation Clients
I'm trying to develop some SharePoint workflows for the company I work for, and I'm not too familiar with the ins and outs of the technology. Normally when I want to familiarize myself with something, I just play with it, look at the properties, find all the methods, etc.
When I fire up Visual Studio and try to create a SharePoint workflow, it gives me an error indicating I don't have a reference to "Microsoft.SharePoint.dll". Someone told me that it was normal to see that because you have to do all your development on the SharePoint Server itself if you want to do workflows. Is this true?
If so, is there anyone out there that has successfully developed SharePoint workflows in a multi-developer environment without resorting to any "hacks"?? Thank you for reading and your responses...
If you want to create a Sharepoint workflow using the Sharepoint Templates, you need to have a Windows 2003 or 2008 Server running Sharepoint. Essentially, that is true for all Sharepoint development: For it to be really efficient, you need to run Visual Studio on a Sharepoint Server. This in turn means that every developer needs his own Sharepoint server and then you have one additional "Staging"-Server where you deploy and test your combined solutions. Suddenly, that MSDN Subscription looks very attractive :-)
As for your Workflow learning question: I can highly recommend "Workflow in the 2007 Microsoft Office System" by Apress.
Yes, you have to do all your development on a the SharePoint server itself. Consider using a virtual machine and package up features that you can deploy to your staging and production environments.
http://weblogs.asp.net/erobillard/archive/2007/02/23/build-a-sharepoint-development-machine.aspx
http://www.wssdemo.com/Pages/EntDev.aspx
Yes, you can develop SharePoint Workflows, WebParts, etc. in a multi-developer environment without any hacks. I suggest you use
a MOSS 2007 VPC Image
Ankhsvn to use svn inside Visual Studio
and also the WSPBuilder Extensions
and maybe you should read What are your biggest complaints about Sharepoint? to see what you're up to ;-)
To learn SharePoint Workflow development,you can start at Step by Step Tutorial. Creating Workflows for Windows Sharepoint Services and MOSS2007
While it's true you need SharePoint installed on your development computer for most SharePoint development, you can get away without it for workflow development. Follow these steps:
Copy the SharePoint DLLs to your development computer (for workflow you'll need microsoft.sharepoint.WorkflowActions.dll).
Open Visual Studio and open the Toolbox tab
Add a new tab (call it SharePoint Workflow Items)
In the new tab, click "Add Items"
Click the "Activities" tab
Locate and add microsoft.sharepoint.WorkflowActions.dll
You'll see a few new tasks show up and already selected.
Once you do this, you'll be able to develop WF workflows that can use SharePoint-specific tasks. Deployment and testing the workflow is another task altogether.
Also, it was casually mentioned in this thread, but you cannot develop SharePoint workflows on a 64-bit SharePoint Server at this time. You will have to have a 32-bit Windows Server and SharePoint Server installation.
Here is a link to some SharePoint workflow how to videos.
http://chrisbarba.wordpress.com/2009/12/21/sharepoint-workflow-how-to-videos/