- This topic is empty.
- AuthorPosts
-
- 12/20/2012 at 1:45 am #5320
AnonymousParticipantHi Jim,
You should not be concerned about any reference to "http://workplacearchitects/*" .
This reference is the XmlRoot namespace attribute of the webpart and controls its XML serialization.
If you want to know more about this please check out this link:
http://msdn.microsoft.com/en-us/library/system.xml.serialization.xmlattributes.xmlroot.aspx
Please note that they create a namespace similar to ours called http://www.cpandl.com.
- 12/20/2012 at 2:00 am #5735
AnonymousParticipantThanks, for the information, . That is good to know. When you say not to be concerned, are you also referring to the hard-coded reference to the client site? That was really what had me concerned. Having migrated pages out of our dev environment to our staging and production environments, those migrated pages still refer to the original dev site in these lines of HTML that refer to workplacearchitects.
Can I ignore the references to the original dev site or is there potential for problems?
Thanks again,
Jim
- 12/20/2012 at 2:13 am #5734
AnonymousParticipantYes, I'm also referring to the client site. Because you migrate the pages you see the references from the Dev to the Stage and Prod.
If you were to create those pages from scratch then you wouldn't see the same references. And yes, you can ignore them.
PS
Can I ask you what toll you use to migrate your pages?
- 12/20/2012 at 2:18 am #5733
AnonymousParticipantThanks again – that is what we had hoped!
We use AvePoint's DocAve for some of it, but most Quest stuff we don't migrate. We just copy/paste XML. DocAve can be unpredictable.
(I am hope I am correct in marking your answer as correct; if I knew that for sure I wouldn't have had to ask. )
– Jim
- 12/20/2012 at 2:30 am #4232
AnonymousParticipantSharepoint 2010, Quest Web Parts 5.7
Also, Sharepoint 2007, Quest Web Parts 5.2
My question is about the purpose and significance of references like the following, which I see in the code-behind for default.aspx, for example. I see references to “http://www.workplacearchitects“. I would ignore them, but the context is what got me concerned.
In the following snippet, I had created a blank site called “quest57Test” and added a single simple custom list called “booksIread”. I then put a qListView on the main page (default.aspx) and referenced my custom list.
<PageUrl xmlns=”http://app01sbx.xxxxxx.com/sites/vacationtracker/quest57Test/default.aspx?PageView=Shared&InitialTabId=Ribbon.WebPartPage&VisibilityContext=WSSWebPartPagehttp://www.workplacearchitects/DataViewer”>http://app01sbx.xxxxxx.com/sites/vacationtracker/quest57Test/default.aspx?PageView=Shared&InitialTabId=Ribbon.WebPartPage&VisibilityContext=WSSWebPartPage</PageUrl> <ViewedLists xmlns=”<Lists>” _mce_href=”http://www.workplacearchitects/DataViewer”><Lists>”>http://www.workplacearchitects/DataViewer”><Lists> My concern is that references to http://www.workplacearchitects/DataViewer always accompany hard-coded references to the original site, in this case, “http://app01sbx.xxxxxx.com/sites/vacationtracker/quest57Test/default.aspx“.
I have checked other sites which we have Development, QA and Production instances of, and they reside in independent web apps. Therefore, they have URLs which differ from one another, as they should.
But the default.aspx page on all these sites, regardless of whether they are Dev, QA or Production, still contain these references back to the original site. In our case, the “original site” would be the Dev site, which is where we begin development. These references are always part of these http://www.workplacearchitects/DataViewer references.
So what I am trying to understand is what is the significance of these references, and should I be concerned that a production site called, for example, http://myapp.mydomain.com would have references in its default.aspx to the original dev site called http://myappdev.mydomain.com?
I have not seen any specific misbehavior that I would attribute to these references, but I do want to make sure we are not looking for trouble by leaving them as they are.
I have reproduced this behavior in our Sharepoint 2010-based Quest WP 5.7 environments as well as our older Sharepoint 2007 Quest WP 5.2 environments.
Thanks!
Jim
- 12/20/2012 at 2:30 am #5732
AnonymousParticipantDo you know that we have a great migration tool?
Take a look to this
http://www.quest.com/migration-manager-for-sharepoint/
I use the tool to migrate complete applications based on QWP and lists/doc libs and more from one env. to another and it works great.
-
- AuthorPosts
You must be logged in to reply to this topic.