I recently migrated custom WebPart template solution (wsp), which has custom list definition, from SP2010 to SP2013 using Visual Studio 2013. Set the Assembly Version to 15 and compiled over .Net Framework 4.5. The deploymnet was successful. But there are 2 problems:
1. When I created site using the custom template that was just deployed, the page displays cluttered icons, attached screen shots. Also when trying to add permission to the site, a whole bunch of colorful cluttered icons appear on the site's Permissions page.
2. The other issue is, some of the CSS, specifically the ms-WPxxxxxxxx (like WPTitle, WPHeader etc) are being inherited, probably from corev4.css. That’s what View Source shows. The custom CSS is defined in the main page (CustomDefault.aspx) with “!important” tag, but that didn’t seem to be of any use.
The same solution was working perfect on SP2010.
Suspect mostly (1) is related to (2), I may be wrong.
To resolve (1), as advised by SP folks from MSDN Community forum, I changed the default master page to Oslo.master ==> that cleared the cluttering icons, but CSS and Javascripts werent working. So I had to revert.
I also tried changing the "../_layouts/.." to "../_layouts/15/..", that didnt make any difference.
MSDN Community Thread:
https://social.msdn.microsoft.com/Forums/office/en-US/f9199e0c-972b-45b9-b8fb-772028bc22d9/cluttered-icons-in-sharepoint-2013-post-migration-from-sp2010?forum=sharepointdevelopmentprevious#74fb3648-9776-4f68-82ba-b212102a1492
Any help will be appreciated.
enter image description here
After a long battle, I finally fixed this problem. Found that the 'onet.xml' in the SiteDefinition module was referring to SharePoint 2010 master page, v4.master. Since this was another project, I did not have a clue that this file will have references to SP2010 resources. Many blogs suggested only to change the resources path like '/_layouts/' to '/_layouts/15/' and the '/ControlTemplate/' to '/ControlTemplate/15/' but not seen anyone mentioning about master page change. Probably may not be the case for a completely out-of-box solution. So search for 'v4.master' (SP2010), in the project solution, if found, change it to your custom master page, if you have one, or to the default master page. But if you have used any other master page or a custom master page that was exclusively meant for SP2010 or an older version of SharePoint, you would have to choose an equivalent one or customize it to make it compatible with SP2013.
So here's the code snippet that was changed and that got rid of the cluttering icons, hope it helps someone out there.
<!-- <Configuration ID="-1" Name="NewWeb" MasterUrl="_catalogs/masterpage/**v4.master**" />
<Configuration ID="0" Name="Default" MasterUrl="_catalogs/masterpage/**v4.master**">
<Configuration ID="1" Name="Blank" MasterUrl="_catalogs/masterpage/**v4.master**">
<Configuration ID="2" Name="DWS" MasterUrl="_catalogs/masterpage/**v4.master**"> -->
<Configuration ID="1" Name="NewWeb" MasterUrl="~masterurl/**default.master**" />
<Configuration ID="0" Name="Default" MasterUrl="~masterurl/*default.master*">
<Configuration ID="1" Name="Blank" MasterUrl="~masterurl/**default.master**">
<Configuration ID="2" Name="DWS" MasterUrl="~masterurl/**default.master**">
Related
If I understood correctly, DNN widget is a way to add a js to every page on the website using module or theme. Right?
My goal evantually is to add a js to every page on a portal and preferably to do that via module that has no need to be added to every page manually.
My plan B is adding module and using setting "Display Module on All Pages", but widget seems to be a better way to do that.
At first I've tried to use this instruction. I've added the YourCompany.Widgets.SampleWidget.js file to root of existing DNN module. Also in the .dnn manifest file inside components tag I've added another component like this:
<component type="Widget">
<widgetFiles>
<basePath>YourCompany</basePath>
<widgetFile>
<name>YourCompany.Widgets.SampleWidget.js</name>
</widgetFile>
<widgetFile>
<name>license.txt</name>
</widgetFile>
<widgetFile>
<name>releasenotes.txt</name>
</widgetFile>
</widgetFiles>
</component>
I've got this error on module installation:
Failure File specified in the dnn could not be found in the zip file: - D:\Projects\website.com.ua\Host\Install\Temp\vp1vioj1\YourCompany.Widgets.SampleWidget.js
vp1vioj1 part is changing every time (seems like it's some unique id that is generating on module install).
Then I tried to place this widget component inside another package tag after checking this article. Like this:
<dotnetnuke type="Package" version="5.0">
<packages>
<package name="ModuleName" type="Module" version="00.00.01">
<!-- some module content here -->
</package>
<package name="YourCompany.SampleWidget" type="Widget" version="00.00.01">
<components>
<component type="Widget">
<widgetFiles>
<basePath>YourCompany</basePath>
<widgetFile>
<name>YourCompany.Widgets.SampleWidget.js</name>
</widgetFile>
</widgetFiles>
</component>
</components>
</package>
</packages>
</dotnetnuke>
But I still got the same error on install. I didn't find any other instructions or documentations regarding widgets. When I tried to check the DNN source code - it seems to be also very time consuming and hard way.
So could you please help me to clarify this?
Support for Widgets in DNN Platformnwas dropped a number of years ago.
Your best option if you want something ok all pages would either be to look at a SkinObject, like the breadcrumb or Login for example. Or a traditional module but marking it “display on all pages”
First, you might want to take a look at the concept of DNN Extensions and how they are built and packaged.
If examples of versions DNN extensions, https://github.com/WillStrohl/dnnextensions. The examples include a widget. So check it out.
Now, what you posted looks like a .dnn file, which the the manifest file that is intended to be a part of a packaged DNN extension. Code and other bits and pieces go into the packaged extension (really a specially named zip file). The packaged extension is installed into your DNN installation via the Extensions Persona Bar page (click the Install Extension there).
From my experience with DNN (2006 to now), I believe that I can say that a DNN Widget is something that I've never had anything to do with. So, you may be barking up an old any dying tree in the project.
If you want something included on every page, it makes more sense to include it in the theme (skin). If you want a javascript file, add that to your theme project and have the .ascx files include it, probably using https://docs.dnncommunity.org/api/DotNetNuke.Web.Client.ClientResourceManagement.html (see https://docs.dnncommunity.org/api/DotNetNuke.Web.Client.ClientResourceManagement.html)
But, if you are determined to use a widget, start with https://www.kalyani.com/blog/2009/12/25/dotnetnuke-widgets-guide-part-1-of-4/
I've discovered how to access the parts within the MSI/Product tag. But my goal was to set the caption of the burn installer based on the Major/Minor version number.
This code below is the summary of what I tried to do, but this doesn't work (I think because I'm not within the Product tag).
Burn wxs:
<Wix>
<Bundle Version="!(bind.packageVersion.<packageName>)" >
<Variable Name="ProductVersionMajor" Value="!(bind.property.ProductVersion.Major)"/>
<Variable Name="ProductVersionMinor" Value="!(bind.property.ProductVersion.Minor)"/>
....
Theme.wxl:
<WixLocalization ...>
<String Id="Caption">[WixBundleName] [ProductVersionMajor].[ProductVersionMinor] Setup</String>
....
Is there some kind of work around where I can get this information at the bundle level without writing custom code?
This answer here was useful, but not quite what it appears I need; since I'm not within the WIX product tag for the inner MSI.
!(bind.property.ProductVersion.Major) is a bind variable when building an MSI, not a bundle. The available bind variables are documented at https://wixtoolset.org/documentation/manual/v3/overview/light.html. There is an open feature request for MsiPackage property bind variables at https://github.com/wixtoolset/issues/issues/4298. It would likely be additional work to get the ProductVersion.Whatever part working, so if you want that then you should add a comment to that issue.
In addition to #Sean's answer, if you are only interested in the full version and not in any breakdown of major/minor/build then the below example I have the caption in the localization WXL file can be defined as simple as:
<WixLocalization Culture="en-us" Language="1033" xmlns="http://schemas.microsoft.com/wix/2006/localization">
<String Id="Caption">[WixBundleName] Setup (v. [WixBundleVersion])</String>
...
and in my bundle.wxs file I have the following definition:
<Bundle Name="$(var.MyProductFullName)"
Version="!(bind.packageVersion.MyPackageId)"
Manufacturer="!(bind.packageManufacturer.MyPackageId)">
...
where the variable MyProductFullName is defined in my variables file under my package's installer project. So basically the [WixBundleName]
and [WixBundleVersion] are bound to the Bundle element's Name and Version attribute values, respectively.
I recenty went through the process of converting all PCL's in my solution to .net standard libraries (not sure if its related nor not, just mentioning it in case).
Now, when I try and add a page, It adds the Xaml and the xaml.cs files into the project without any link or connection, so they wont compile:
Googling suggests I can go in and edit the .csproj to add a dependency between the two, but this is a horrible solution long term.
Any way to fix this "properly"?
I've tried dragging and dropping existing files in from windows explorer into VS2017, adding new through the add new dialog, adding existing through add existing and it all exhibits the same behaviour.
Thanks
OK, to answer my own question. Seems like you need to put in a workaround for the time being:
https://forums.xamarin.com/discussion/comment/288205/#Comment_288205
In the .csproj:
<ItemGroup>
<!-- https://bugzilla.xamarin.com/show_bug.cgi?id=55591 -->
<None Remove = "**\*.xaml" />
< Compile Update="**\*.xaml.cs" DependentUpon="%(Filename)" />
<EmbeddedResource Include = "**\*.xaml" SubType="Designer" Generator="MSBuild:UpdateDesignTimeXaml" />
</ItemGroup>
And remove all existing XAML Pages referenced in the .csproj file such as EmbeddedResources and Compile directives
Not sure if this is the right place to ask the question, but...
I've got the following xliff file:
<?xml version="1.0" encoding="UTF-8"?>
<xliff xmlns="urn:oasis:names:tc:xliff:document:1.2" version="1.2">
<file original="file1.txt" datatype="plaintext" source-language="de-de" target-language="en-us">
<body>
<trans-unit id="unit_5">
<source xml:lang="de">unit_5</source>
</trans-unit>
</body>
</file>
</xliff>
I try to open the document as "translate single document" and get the following error from the image below. What might it be?.
I just opened your xliff file in Trados Studio 2014 (SP1) without any error messages coming up. I am afraid I do not really understand what Studio was complaining about for you: the file looks fine to me.
Did you try to disable schema validation in the file type settings for XLIFF, just as a workaround?
Best,
Jenszcz
Generally, file[source-language] and trans-unit[xml:lang] should have the same value. I'm not sure if it's allowed to use different notations (de, de-de).
Also, I've found Trados to be a bit strict and sometimes you'll see that even if the specs allow for some elements to be missing, in some cases Trados still expects them to be present. I'd try putting the target node inside trans-unit and see if it works.
From the XLIFF 1.2 spec:
The optional xml:lang attribute is used to specify the content language of the <source> this should always match source-language as a child of trans-unit but can vary as a child of alt-trans.
So I think it's probably the mismatch between de and de-de that is causing the complaint. You could align these values, or just remove xml:space from the <source> element entirely, as it is optional in this context.
I'm writing a Windows Store app, and I'd like to know if it's possible to suppress the generation of the "Common" folder, containing the code from Microsoft, which - imho I do not need.
Any ideas?
Cheers
Common contains StandardStyles.xaml which per App.xaml:
<!--
Styles that define common aspects of the platform look and feel
Required by Visual Studio project and item templates
-->
<ResourceDictionary Source="Common/StandardStyles.xaml"/>
and in StandardStyles.xaml:
<!--
This file contains XAML styles that simplify application development.
These are not merely convenient, but are required by most Visual Studio project and item templates.
Removing, renaming, or otherwise modifying the content of these files may result in a project that
does not build, or that will not build once additional pages are added. If variations on these
styles are desired it is recommended that you copy the content under a new name and modify your
private copy.
-->
That said if you've determined it's not something you'll need just delete it, simpler and less fragile than hacking a T4 template (or whatever mechanism is used) for the code generation.