Does anybody knows how to develope a new language pack for Microsoft Dynamics CRM?
Thanks in advance.
I think you would like to know how to develop a complete new language pack (like the ones you could download here 'Language Pack Downloads'
Sadly, there is no supported/documented way to build own language packs. However if you are interested in how to translate your own entities then take a look at 'Support for Multiple Languages'
Related
I'm working on a Windows Application that has been around more than 20 years. It has a help file (.chm) that is built manually outside of the solution (i.e. not by Visual Studio or MSBuild) by compiling it in Microsoft HTML Help Workshop 1.4 from 1999. I would like to migrate this to the latest format such that it can be built as part of the release mode build process.
Is there a way to import the project (based on .hhp file) into a tool that builds the modern .mhsc-format help files? According to this Wikipedia article there was something called Microsoft Help 2 which was "the help engine used in Microsoft Visual Studio 2002/2003/2005/2008", which came after HTML Help Workshop and was succeeded by Microsoft Help Viewer, which was supported starting with Visual Studio 2010.
Preferably, there exits a way to migrate the .hhp/.chm project directly to Help Viewer, or maybe I have to download VS2010 and do it in two steps if indeed those two migrations are themselves supported. This stuff is so old it's hard to find relevant information on it. Thanks.
MS Help Viewer (.mshc) was difficult to manage at the time. It was made mainly for companies like Microsoft who code their help from a database.
You'll find some viewers and tools like MshcMigrate e.g. getting you from .CHM and .HxS -> .mshc.
There is no longer any need to purchase a mshcMigrate licence. The licence is free to use See also free key.
If you expect the users of your application to have internet access, another approach is to publish the help as HTML pages on a web server and link directly to those from your application.
Before migrating please note (for your existing workflow) the CHM Viewer is part of the Windows OS. A special viewer isn't required.
I've been exploring UIPath community edition and have come across that the Main window and most of its activities are just like a Visual Studio Workflow. Is it right to say that UIPath is built upon Workflow Foundation of .NET Framework? I'm just trying to reconcile them both in my head now.
Yes that is correct. You can use many functions and methods within UiPath that come from .net. If you press crt+space when you are typing code you will get a list of all functions and methods available. You can even invoke code and execute previously saved Microsoft code.
Not only it's build using Microsoft Workflow Foundation but you could also extend UiPath using Activities build in very similar fashion to WFF. So if you know how to create NativeActivity for example, you already know how to extend UiPath.
Note that the development in UiPath is not really code-extensive, knowledge of .NET is a plus but not mandatory.
What is the new Microsoft way of UI prototyping since VS2015 doesn't support SketchFlow projects. (I'm having hard time to accept that they removed such a useful tool without providing alternative)
I know we still have PowerPoint StoryBoards for basic UI mock-ups but I would like to use interactive prototypes through Visual Studio. Therefore please do not suggest alternative products
Several years ago, I did some pretty serious Office add-in development for Office 2003 (Word, Excel and PowerPoint). I created some shared COM add-ins in C# using Visual Studio 2003. At the time, I looked at VSTO, but decided for reasons that I can't fully remember that it was not suitable for my needs.
My add-ins are due for an upgrade now, and no longer need to support Office 2003 - though they do still need to support Office 2007, not just 2010.
I know that things have moved on significantly, and that Visual Studio 2010 has better support for Office development. I'd like to determine whether I should re-implement my add-ins using VSTO, or continue with the shared COM add-in route.
If anyone knows of a nice summary of the pros and cons of each approach (beyond the marketing hype), I'd love to hear it.
Things that I found very frustrating first time around (not using VSTO, but may apply anyway):
the need to manage COM references explicitly (and call
ReleaseComObject everywhere)
the need for a COM shim to get the security model to work
visual studio installation projects just plain didn't work; I ended
up building my own MSI-based installer
lack of documentation, particularly on all of the above; I spent
weeks of trial-and-error and searching random blogs; the MS-supplied
example code completely ignored all of these real-world issues
It's also worth mentioning that minimising the amount of stuff that needs to be installed prior to my add-ins is important. I think that one of the things that put me off VSTO was the need to deploy additional stuff (though since I never went down that route I don't know if that concern was justified). And I'd really like to be able to deploy on a standard Windows 7 (or Vista) build without the need to first install (say) .NET 4.
Partial answer but too long to fit in a comment:
Parts I can comment on:
Setup projects for VSTO addins now do actually work and there is a very good walkthrough available on how to create them properly.
Documentation in general of the office object model is poor imho and that should be equally annoying for com and c# development. Because a lot of the objects are now returned as dynamics if you use .net framework v4 you loose intellisense which does not help. The workaround for that is to be explicit in casting to known types where possible.
In order to run it obviously needs the relevant framework installed (v4 is FAR better for this than earlier version because of dynamics, optional arguments that were added under pressure from the office group and the NoPIA setting) Besides that it also needs the VSTO runtime installed.
All of these dependencies could be incorporated into the installer but they are required
You haven't specified what you used to create those com addins (My guess is c++ or vb6) and I can't tell how large they are and how much overhaul they need so it's not really possible to give advice if now is the time to make the change. One of the areas where moving to c# will certainly be far cleaner and nicer is anything related to ribbons. But again I can't estimate how relevant that is for you.
Is it possible to create an add in that works on all office versions?
I searched the msdn and different forums but there is nothing specific about this issue.
Difficult if you use VSTO, because you'll need to deploy/assure different runtime libraries. See the VSTO entry in Wikipedia, not to speak of different development and test platforms (which you may already have, if you aim for it).
There's a MSDN Blog from Mary Lee the migration of 2007 to 2010 projects.
Please see also this blog from Andrew Whitechapel: Can you build one add-in for multiple versions of Office?
From a pragmatical point of view ("time-to-market"), you may consider the use of a third-party-tool (www.add-in-express.com), which allows the creation of version-independent add-ins.