I am attempting to migrate from an on-premise installation of TFS 2012 to Visual Studio Online. I have a handful of projects that have been in existence since TFS 2005 and have been upgraded/migrated up to 2012. Only one of those projects has any significant work item activity that I really need to maintain.
That project is using the MSF for Agile Software Development 6.2 template. I have never made any customizations to the template to my knowledge over the years. However, since it has been upgraded / migrated I am not surprised that the template is causing the OpsHub utility issues.
For every Work Item Type in the project, the fields 'Area Id' and 'Iteration Id' show as red errors on the validation screen of the tool for this specific project.
I have already tried the solutions suggested here, but it seems to have made no difference whatsoever. The template on VSO is MSF for Agile Development 2013.3. After looking at the WIT definition files in that template I can see that there is no 'Area Id' or 'Iteration Id' fields (or 'AreaID' or 'IterationId' for that matter) defined. However, in the 6.2 templates that field is specifically defined.
I am sure this has something to do with those being System defined fields and no longer needing to be defined in the individual work item templates or something of that nature. The fields cannot be deleted because they are System fields.
In any case, I have not been able to find a solution to this problem so that I can complete running the OpsHub tool to migrate this main project over. Any help would be greatly appreciated.
As an aside, every one of my projects are showing 'Template Customization or Template Mismatch' errors. For the meantime, I am just trying to resolve the issues with this one main project. I may be able to forego migrating the Work Item Data for some of the other projects.
Thanks in advance!!!
In the move from 2008 to 2010 Microsoft changed a number of the built in fields. These fields do not appear in the template, but if you export the work item type from the instance of the process template you will see them.
Effectively an upgraded server has built in fields that never changed and the OpsHub tool craps out on fields that it should be ignoring.
The only solution, bar OpsHub fixing it, would be to try and change the field names to match what is expected.
You can use the witadmin.exe to make the change.
Related
I have a local Sitecore instance where I made changes involving both code and the creation of a new sublayout.
After deploying the code I can see on the new environment the usercontrol (.ascx) file associated to the sublayout, but the corresponding item does not appear and cannot be used.
If I attempt to recreate the usercontrol, it tells me that the file already exists, and due to my lack of experience with the platform I found myself unable to import it.
What would be the optimal way to proceed?
To deploy your new sublayout correctly you should create a Sitecore Package. This is basically a zip file that allows you to move both items and disk files between Sitecore instances in a controlled manner. For basic installs of Sitecore, where you have not added any specialised tools, it is generally the preferred way to move resources between servers.
The "Package Designer Guide" on the Sitecore Developer Network will give you information about how to use the Sitecore UI on your development site to create a package containing both the Item(s) and the file(s) for your sublayout:
http://sdn.sitecore.net/upload/sitecore6/65/package_designer_admin_guide-a4.pdf
Once created, this package can then be imported onto whatever other servers you want to deploy your sublayout to.
-- Edited to add --
Derek Hunziker's answer makes a good point: As well as the basic Sitecore behaviour there are third party tools available which can enhance and extend the deployment experience if you wish. As well as Hedgehog TDS, you might also consider:
The "Sitecore Rocks" extension for Visual Studio allows the creation of packages from within the
Visual Studio UI. This tool is free to use. (https://visualstudiogallery.msdn.microsoft.com/44a26c88-83a7-46f6-903c-5c59bcd3d35b/)
There are also a variety of open source tools - Sitecore Courier is one example: (https://github.com/adoprog/Sitecore-Courier) This is designed to help automate deployment between Sitecore instances.
Both TDS and Courier are most suited to regular deployments, such as those during ongoing development cycles, since they both include automation to help decide what gets deployed. The standard Sitecore UI and the Sitecore Rocks extensions for package creation are better suited to ad-hoc deployments, since you generally pick the things to deploy manually.
A common best practice is to deploy your items along with your code using Team Development for Sitecore. This eliminates the need to create Sitecore packages every time you want to move items between environments, which in turn reduces issues caused by human error. As an added bonus, the items that you own as a developer (such as Templates and SubLayouts) can be checked into source control.
Full disclosure: I work for Hedgehog Development :)
I'm using VS 2013 and SQL Svr 2012 and trying use EF to populate a gridview. As this is a very simple test, I have just one table with a key and a couple of data fields. The process of creating the model seems to work fine - it shows as expected in the designer view, the files are created in app_code, a bin folder is created with 2 dlls, and the config file is updated with a connection string and other entries.
When I try to select the "named connection" I get the error "Unable to load the specified metadata resource" and it talks about rebuilding the project to get the assemblies.
I've spent hours reading other cases like this and I can't understand:
Why this is happening when it was never a problem with VS 2010
How do I fix the connection string to point to the resources it wants. I'm totally lost with all the technical advice about fully qualified assembly names - nothing I try works.
How do I set some parameter to force the resources to be in the proper place? All the advice I've read doesn't seem to relate very well with VS 2013
I need to decide if I should just uninstall VS 2013 and use VS 2012. Currently, I'm using VS 2010 with ASP 4.0 and I'd like to move to ASP 4.5 and generally keep up with Microsoft technology. However, I don't have the skill level to deal with a VS release that is buggy. It seems to me that this EF execise could be due to a either a bug or some odd corruption on my computer - I'm trying to figure out which is the case. I installed VS 2013 Express and SQL Svr 2012 on a clean machine that had none of these tools in the past.
I'd really like to see someone who is very familiar with Visual Studio try to replicate my problem as it only takes a few minutes to do so:
In MS SQL Server, create a tiny DB with one table that has a primary key and a couple of data fields and populate with some test data - Call it TinyDB with TestTable1.
Using VS 2013 Express for Web, create an "New Web Site" with the option for "ASP Empty Web Site" using VB.
Add an ASP App_Code Folder containing an "ADO.Net Entity Data Model" and leave the name as "Model".
Generate the model from the DB and make a "New Connection" for "TinyDB" and using Entity Framework 6.0 and then select "TestTable1". Note the namespace is "TinyDBModel". Clicking "Finish" will generate several items in App_Code, other folders and also update web.config.
Add a web form called default.aspx and drag a gridview onto it. In design mode for the gridview, select "new data source" and then the "Entity" option (note name of EntityDataSource1 which appears in default.aspx). Click next and under "named connection" select "TinyDBEntities" - this is where mine gets the error "Unable to load the specified metadata resource".
Note that this exact exercise in VS 2010 works perfectly and produces a grid with the correct data displayed.
Unfortunately, the EntityDataSource control does not work with the latest version of Entity Framework, EF6. Hopefully the control gets an update in a future update version of VS or EF, but for now you can't use the two together.
There are a few solutions / alternatives:
Drop back to EF 5. In order to do this, delete the .edmx and .tt files from the App_Code folder, delete the EF assemblies from the Bin folder, and remove the references to EF from web.config. Then rebuild the site, add a new ADO.NET Entity Model and choose version 5 in the Choose Your Version dialog. Then delete the .tt files from the App_Code folder, open the EDMX diagam, right-click an empty spot and on the Properties Grid set Code Generation Strategy to Legacy ObjectContext. Then rebuild again, and it should work.
Use Model Binding. This is really the recommended solution. The Microsoft / EF team recommends people to stay away from the EntityDataSource control and only use it for Dynamic Data web sites, Model Binding is the preferred solultion. It's pretty clean and straight forward to use, and gives you a lot of control over your queries and object updates. For more info about Model Binding, check out: http://www.asp.net/web-forms/tutorials/data-access/model-binding/retrieving-data
Just stumbled upon this question today:
"Is there a way to know that MPP published to the project server is not created using a template available on the server?"
Basically this comes from the point that how to find out compliance of the project plans to the standard templates.
I am not aware how it can be done?
Actually there is no way to identify by one field that this project was created using that template.
You may assume that by Enterprise Project Type, but again there is a way to change EPT for existing project.
The only way I know is to compare a template and a project by tasks, by structure, etc. it works like finger print recognition: you select several points which the most probably tell that the project was created from the template.
The worst case I can imagine: a user creates a project by a template and after that removes everything from the project. Formally the project was created by the template but in real there is nothing from the template left in the project.
I just upgraded from ActiveReports 2.0 to 3.0. All rpx files have been converted to *.vb files. The ActiveReports project has this class hierarchy:
*.vb with designer -> PrintBase.vb -> ActiveReport3
When I opened any of the *.vb files, I got this error:
The designer could not be shown for this file because none of the classes within it can be designed. The designer inspected the following classes in the file: xxx --- The base class 'PrintBase' could not be loaded. Ensure the assembly has been referenced and that all projects have been built.
Call stack:
at System.ComponentModel.Design.Serialization.CodeDomDesignerLoader.EnsureDocument(IDesignerSerializationManager manager)
at System.ComponentModel.Design.Serialization.CodeDomDesignerLoader.PerformLoad(IDesignerSerializationManager manager)
at Microsoft.VisualStudio.Design.Serialization.CodeDom.VSCodeDomDesignerLoader.PerformLoad(IDesignerSerializationManager serializationManager)
at System.ComponentModel.Design.Serialization.BasicDesignerLoader.BeginLoad(IDesignerLoaderHost host)
Then I went through PrintBase.vb. There was no compile error. Then I modified one of the *.vb files to this:
Hello.vb -> ActiveReport3
The designer worked without any problems. The PrintBase has quite a bit of code. To simplify the debugging, I created a new .vb file called BasePrint that inherits from ActiveReport3. So, the hierarchy is back to:
Hello.vb -> BasePrint -> ActiveReport3
Then I saw the same error above again. It seems like AR3 designer does not allow .vb files to inherit from a base class according to my debugging. But I am not quite sure. BTW, the ActiveReports project is vb.net. There are other C# projects under a VS 2008 project solution. Is the mixing of VB.NET projects and C# have anything to do the miagration / upgrade process?
Thanks.
Indeed, the class-style inheritance was not supported by the upgrade utility in the ActiveReports 3.x designer. However, after an upgrade is complete you should be able to put the base class bad (the way that you described) and the designer should safely ignore it. If you're still having problems try to close the project, do a clean (delete the old assemblies that might be referncing the old PrintBase class) & close visual studio and reopen it again to get a fresh start.
You can find more information about upgrading reports from ActiveReports 2.x to ActiveReports 3.x at the following page: link text
However, it seems you are using inheritince in this case to share some utility methods and maybe some state (e.g. in class-level fields maybe). For this it is best if you have your reports inherit directly from ActiveReport3 and use "BasePrint" as a sort of utility class that your reports call functions in. Normally this has no disadvantage other than having to prefix the method calls with the name of the corresponding BasePrint instance/variable name and it simplifies dealing with ActiveReports designer in the scenario you describe.
However, ActiveReports does support a visual inheritence that allows a base report to share controls with a derived report. There is more information on how to use this feature at the following location: http://www.datadynamics.com/Help/ARNET3/ar3tskInheritance.html. However, I want to stress that this is a different style of inherience than you are using so it may not be applicable to what you need.
Also, you should try to convert again without having a combined solution with C# and VB projects. I don't know that this is a problem but it is certainly not the most common way the converter is used and may be complicating things.
Finally, you should be aware that ActiveReports 6 is now available and you may want to consider trying out that version.
If you continue to have any problems please contact our support team at support#grapecity.us.com or use our public forms that have many ActiveReports experts monitoring them every day at the following links:
http://www.datadynamics.com/forums/73/ShowForum.aspx - ActiveReports 3 Forum
http://www.datadynamics.com/forums/82/ShowForum.aspx - ActiveReports 6 Forum
Scott Willeke
GrapeCity / Data Dynamics
We're looking into setting up a proper deployment process.
From what I've read there seems to be 4 methods of doing this.
Copy & Paste -- We don't want to do this
Using the "Package" mechanism built into the Salesforce Web Interface
Eclipse Force IDE "Deploy to Server" option
Ant Script (haven't tried this one yet)
Does anyone have advice on the limitation of the various methods .
Can you include everything in a Web Interface package?
We're looking to deploy the following items:
Apex Classes
Apex Triggers
WorkFlows
Email Templates
MailMerge Templates -- Can't seem to find these in Eclipse
Custom Fields
Page Layout
RecordTypes (can't seem to find these in Website or Eclipse)
PickList items?
SControls
I recommend the Force.com Migration Tool.
For reference:
Force.com Migration Tool Documentation
Migration Tool Guide
The Migration Tool allows you to use ant targets to move your metadata between salesforce.com organzations.
I can speak to this from recent painful experience.
Packaging: this is a very old method that predates the metadata API on which both Ant and Eclipse rely. In our experience, packaging's only benefit is in defining your project. If you're using Eclipse (which we do, and I recommend), you can define your project as being based on a particular package. As long as you remember to add new components to your package, your project hangs together
One thing that baffled us for a while, btw, are the many uses of package. We've noted the following:
Installed packages: these come in managed and unmanaged flavors and are really, in the words of a recent post on the SFDC boards, for ISVs to deploy their stuff into various unknown orgs "out there". Both managed and unmanaged packages have limitations that make them unsuitable and unneeded for deployment from development to production within an org, or in any case where you're doing custom development and don't intend to distribute code to a large anonymous base.
Non-installed packages: this is what you see when you click "Packages" in the web UI. These, that we sometimes call "development packages", seem to be just a convenient way to keep a project definition together.
Anyway, the conclusion I'm coming toward is that our team (custom development, not an ISV) does not need packages in any form.
The other forms of deployment, both Eclipse and Ant, rely on the Metadata API. In theory they are capable of exactly the same things. In reality they appear to be complementary. The Force.com migration tool, built into the Force.com IDE for Eclipse, makes deployment as easy as it can be (which is not very) and gives you a nice look at what it intends to deploy. On the other hand, we've seen Ant do some things the IDE could not. So it's probably worthwhile to learn both.
The process we're leaning toward is to keep all our projects in SVN, and use the SVN structure as the project definition (Eclipse will work with this and respect it). And we use Eclipse and sometimes Ant for migration. No apparent need for packages anywhere.
By the way, one more thing to be aware of -- not all components are migratable. Some things must be reconfigured by hand in the target environment. One example would be time-based workflows. Queues and Groups also need to behand-created, I think. Likewise the metadata API can't directly process field deletions so if you deleted a field in your source, you need to delete it by hand in the target. There are other cases as well.
Hope that's useful --
-- Steve Lane
As of Spring '09, mail merge templates are not supported in metadata but record types are. You will find record types as an XML element in the file for the object they belong to. Everything else on your list is supported with a small exception. Picklist values for standard fields cannot be edited in Spring '09. Stay tuned for news on Summer '09 feature announcements.
Update: Standard picklists on standard objects are now metadata exposed (as of API v16):
http://www.salesforce.com/us/developer/docs/api_meta/Content/meta_picklist.htm
Otherwise, Steve Lane's response is pretty accurate. The advantage of using unmanaged packages (what Steve calls non-installed packages) is that when you add metadata to a package, the metadata it depends on will automatically be added. So it's easier to grab a full set of metadata containing all its dependencies. If you are repeatedly moving metadata from one org (sandbox) to another (production), Steve's approach is probably the best way to go and certainly the most common today. I frequently use unmanaged "developer" packages to move something I've developed in one org to another unrelated org. For my purpose, I like to have the package defined in the org as opposed to an Eclipse project / SVN. But that probably doesn't make sense if you are doing team development across many dev/sandbox orgs and are using SVN already.
Jesper
Another option is to use Change Sets if you want to move meta data from a sandbox to production.
There are currently some limitations on how change sets can be used:
Sending a change set between two organizations requires a deployment
connection. Currently, change sets can only be sent between
organizations that are affiliated with a production organization, for
example, a production organization and a sandbox, or two sandboxes
created from the same organization.
From the docs:
A package must be managed for it to be published publicly on AppExchange, and for it to support upgrades. An organization can create a single managed package that can be downloaded and installed by many different organizations. They differ from unmanaged packages in that some components are locked, allowing the managed package to be upgraded later. Unmanaged packages do not include locked components and cannot be upgraded. In addition, managed packages obfuscate certain components (like Apex) on subscribing organizations, so as to protect the intellectual property of the developer.
Advantage to managed package would be that it allows you to easily version and distribute things across multiple SFDC organizations.