I'm looking for a way I can bulk update media items currently with Sitecore Powershell, but happy to here of any other suggestions.
I need a way of swapping out the blob value of a Sitecore media item for another media item. Is this even possible with Sitecore Powershell?
With 4.0 updated this week there will be a great way to do this using the new Remoting module functionality that Michael added as part of this issue. If you cannot hang on for a few more days feel free to contact me directly and I can pass the release binaries earlier.
I wouldn't honestly send remote files to server with the previous implementations as the files were going through serious serialization/deserialization in the process.
However if your files are already on the server there is another way that ingests files from the server file system into the media library that you can check out in a gist I've written a while back here.
InterWorks has a Workbook SDK as part of its Power Tools for Tableau product. Does anyone know how they are able to do this? The SDK can access a workbook without Tableau Server so I don't think it's the JavaScript or REST API.
A Tableau workbook (.twb) file is in XML format. The structure may change between versions, but is relatively straight forward to follow. Most Tableau file formats are also XML. The formats ending in an x (like .twbx) are zipped directories that contain the XML file along with other files.
This means it is not too tough to read information from these XML files, or even modify them. I've edited them by hand in rare cases. Usually there is a better choice than hacking the XML internals, but you can. Just backup your file first, and don't expect Tableau support to help you if it leads to strange behavior on your workbook.
In addition to the Interworks SDK (which is a COTS product), Chris Gerrard published a free Ruby library for accessing Tableau workbooks https://rubygems.org/gems/twb (or gem install twb) and released the source on github https://github.com/ChrisGerrard/TWB, along with a few (but not all of) the scripts he's written that use the twb classes https://github.com/ChrisGerrard/TableauToolsRuby.
Chris gives some useful examples and scripts on his blog Tableau Friction, including this clever article on automatically documenting the relationships among calculated fields
http://tableaufriction.blogspot.com/2015/02/more-calculated-field-analysis-fields.html
Using twb, you can write simple Ruby scripts easily to look at workbook structure. Since Tableau can change the format when they release new versions of the software, using the SDK or twb Ruby gem could isolate your scripts from changes to the format.
Tableau has also released a Document API that supports a modest number common changes to workbooks - so you can write a script to say, update the connection string on a set of workbooks.
So you have at least four choices:
Use Interworks SDK and tools that come with support, documentation and a price tag.
Use the free open source twb library, and either reuse existing Ruby scripts or develop the ones you need. And hopefully contribute the source if you extend.
Roll your own XML parsing scripts.
Use the Tableau Document API if it supports your use case. https://github.com/tableau/document-api-python
In all cases, do backups and be prepared for some adjustments when Tableau releases a major or minor version update. Patch releases are pretty safe.
I'd really like to get a CRM solution under source control but there are a lot of issues. I was excited to see the SolutionPackager tool - thinking MS finally gave us a way to do this. However the tools to export the solution, extract it to files and check it into source control are not integrated. I'm working on a C# project that ties everything together because it's easier to work with the APIs in a single C# solution than deal with a combination of command line utilities such as tf.exe, PowerShell commandlets and plain old .cmd files.
Source files for plugins and Silverlight pages are easy to deal with but I'm looking to get all of the customizations under source control. SolutionPackager works well for tracking customizations made in the CRM interface, but fails in a lot of other areas. I want to create VS solutions for my web resources and reports but I have issues with the VS project and solution structures. SolutionPackager expects to find things where it puts them for repackaging and I'm sure it would not like to see a bunch of .sln, .csproj and .vspscc files interspersed with them.
I figured putting the VS solutions in a separate folder would be the answer but it's not easy. If I create a project for my web resources and try to put my existing .html, .css and .js files into it it wants to copy those into the project folder. I have to remember to use "Add As Link" each time. Worse yet, if I try to do the same with SSRS reports, the "Add As Link" feature isn't even available.
Has anyone done this successfully? I'm open to any suggestions.
I have seen below link but i have not get chance to implement it.when i have try it will post information.
http://blogs.msdn.com/b/crm/archive/2013/05/17/release-alm-for-microsoft-dynamics-crm-2011-crm-solution-lifecycle-management.aspx
I'm new to PS so I may get some of the terminology wrong.
If you want to roll out a custom PowerShell environment (snap-in) for a team of 30 developers/DBAs. What is the best way to do this... if you intend to be rolling out new functionality once a week? Does PowerShell 2.0 help in this regards?
Assumption:
There is no issue with everyone on the team installing PowerShell (v1 or v2)
Update:
Also see Jeffrey Snover's answer about v2 below.
It will depend to a certain extent on the sort of functionality changes that you intend to do. For our environment, we roll out a pretty standard PS install then add one line to everyone's profile to run a script from a shared folder on a server. Then in that script I can do whatever customization that I want to have applied to everyone.
We add the line to the machine specific MS profile (the one in %Windir%) this was an intentional choice. We do it that way so that the users essentially only get this on their production boxes. That way when they write something they can quickly log into a test box and run the script to make sure that the script will deploy without nay dependencies on these customizations.
Currently the customizations are pretty mundane. Mostly just some added functions and aliases. I also have a logger that I wrote in C# specifically for powershell so it loads that up from the dll that is in that same network folder.
Because I play around with my environment so much, I have this in my profile :)
$ProfileDir = ([System.IO.Directory]::GetParent($profile)).FullName
$localMSProfile = "$PShome\Microsoft.Powershell_profile.ps1"
$localAllProfile = "$PShome\profile.ps1"
$userAllProfile = "$ProfileDir\profile.ps1"
$userMSProfile = "$ProfileDir\Microsoft.Powershell_profile.ps1"
$allProfiles = ($localAllProfile, $localMSProfile, $userAllProfile, $userMSProfile)
This is why we added MODULE support in PowerShell V2 - it is the easiest mechanism to xcopy deploy sets of functions. The Module documentation is pretty light at this point but should be much better in a month or two.
Experiment! Enjoy! Engage!
Jeffrey Snover [MSFT]
Windows Management Partner Architect
If you are rolling out a new version of the snap-in weekly, switching version probably won't help with that part of things. However, you'll be developing on a newer platform, with the advantage of the extended functionality that comes with it.
As already suggested some scripts could ease the deployment pain to the point where you have to do nothing but maintain those scripts correctly and keep producing new builds.
We have been using .Net and Visual Studio for the last six years, and early on developed a number of web based reporting applications using the .Net version of Crystal Reports that was bundled with Visual Studio. I'm unimpressed with that product: It seems incredibly difficult and convoluted to use. We had to make security changes, install various extra software, and so on.
Now, we are moving to VS2008 and version 3.5 of the .Net framework, and the time has come to redevelop old applications. Our Crystal .Net developers are long gone and I face a decision: Do we stick with Crystal or move to something else? We have the "full" version of Crystal Reports XI at our disposal.
We produce PDF versions of data extracted from various databases. Some apps use the built-in Report Viewer but this seems redundant with the flexibility of grid views. We still need to produce printable PDFs in the grid or in a downloadable Excel format.
Is Crystal Reports .Net worth persisting with, or should we work out how to use version XI?
Alternatively is there a simple and low cost way to generate PDF reports without using Crystal?
I have experience with reporting in CrystalReports (trying lite version bundled with Visual Studio), ActiveReports from DataDynamics (4 years, full version), Reporting from Telerik (trying trial version) and XtraReports from DevExpress (last one year).
I think ( and not only me :) ), the CrystalReports are most uneficient tool ( developer productivity ) from this tools. The DataDynamics are much, much more better, bud is littlebit buggy :(. Last year we decided to change reporting suite - we have choosen a XtraReports ( with source code ), and I'm totaly happy. The price is little, no bugs ( to now :) ), wonderfull support, and ( the most important ) the productivity was grown a lot.
I recomend you DevExpress's or Telerik's reporting tools.
I would recommended i-net Clear Reports (used to be i-net Crystal-Clear). It can read your existing *.rpt files. Has a better and easier-to-use API (which I admit is not saying much...).
Like you, I've had poor experiences with Crystal Reports, and my gut instinct is to post "avoid it at all costs" in all caps with lots of exclamation points. However, I've had my afternoon nap today, so I'll post like a grownup.
If all you're looking to do is pdf-ize (yes, it's a real word, damnit!) then you might look into some of the PDF widgets like ABCPDF and the like. It's relatively easy to pop a well-formatted web page into a PDF document and be done with it.
However, if you need tight report formatting, consider sticking with crystal reports -- you have a big investment and knowledge base in the technology. Or, alternately, you could switch to ActiveReports or SQL Server reporting services.
I guess the cost/benefit analysis is the cost of retraining your dev team, and investing in the new technologies.
Move away from CR: just get a good PDF generator and Excel engine for .NET, and feed those using your own database code. You can use all the powerful .NET features, including LINQ, without having to wrestle with the Crystal Reports runtime and its woefully inadequate documentation and support.
I can suggest that the built in Microsoft reporting framework works adequately. You can do local reports or MS SQL server based reports. There is a client control that displays reports and can export to formats such as pdf and Excel. Visual Studio can handle report design for the stack.
As far as if it is better than Crystal Reports, I'd say check it out and see if you like it any better or worse. I've worked with the Microsoft Report Viewer more than Crystal Reports but both seem to be fairly similar. Offhand, Crystal Reports seems to be a more advanced reporting tool but more complicated.
I'm not sure about how to utilize the Microsoft Report Viewer infrastructure outside of Visual Studio. If you are using Visual Studio it should all be available in there and you can follow the online help instructions for deploying the pieces for your servers to your servers.
I have used ActiveReports from DataDynamics and Crystal Reports. Of these two, I would recommend ActiveReports above Crystal based on ease of use and, more importantly, future maintenance.
We use Crystal in our shop too. We are currently on 8.5, which is way old and is no longer supported by SAP. We tried to upgrade to CRXI recently, which involved an entirely new API. We had to shelf the effort due to other priorities. While working on the upgrade I found support for CRXI on a number of forums. Google it.
I believe you can find a cheap way to generate PDFs without using Crystal. I believe Adobe gives the creation part away for free. I would visit their site and look into it.
I would recommend staying with Crystal only if you had a lot of reports that were already using that technology.
Get out of Crystal Reports. They are poor.
Check out SQL Reporting Services. It works very well with .NET. Try it out. There is a learning curve, but when is there not?
IMO, you should consider other criteria as well such as:
Cost of the software
Integration with your .NET applications
API and Programmatic flexibility (All said and done, there are always the "customizations" and tailoring. For such scenarios , developers eventually fall back on programmatic solutions vs. out of box
Now, in my experience (having used both Crystal Reports and SSRS(2005/2008) , though Crystal Reports does come with a friendly set of API, it fails in many basic criteria and developers end fighting the software. This is I say based on my experience with SSRS where developers are far more comfortable with. For starters, it uses XML extensively and the provision to use custom code assemblies does not harm either.
--I think you would where I am getting at---
"Consider & Evaluate SSRS*. If you are hesitant at first, then do a Proof of Concept and test your requirements. I have a feeling you will be pleased with what you see
especially considering your requirement of using PDF format.
Developers, especially , MSFT specialists will thank you
Leverage the Programmatic rendering of the reports (though it sounds fancy , trust me , its not more than handling an API call
For e.g.:
public Byte[] Render
(
string Report,
string Format,
string HistoryID,
string DeviceInfo,
[Namespace].ParameterValue[] Parameters,
[Namespace].DataSourceCredentials[] Credentials,
string ShowHideToggle,
out string Encoding,
out string MimeType,
out [Namespace].ParameterValue[] ParametersUsed,
out [Namespace].Warning[] Warnings
out string[] StreamIds);
Member of [Namespace].ReportingService
)
--- where Format will be "PDF"
Hope you find this relevant