I'm hoping I just missed something in the README somewhere, but...
I have a library of VB.net code that I'm trying to package into a PCL, ultimately for use under Xamarin. The code is relatively straightforward, there's a lot of File I/O using streams and some SQL client code, and a smaller amount of UI and control related code.
So I made a new PCL project, but I was confused what to select, so I chose Windows Store and .Net 4.5. I then Add...ed the source files from an existing project. Now I'm getting errors on the most basic things - ArrayList does not appear to exist in spite of importing System.Collections, and StackTrace doesn't exist in Diagnostics. Even simple things like StringFormat and SortedDictionary aren't there.
Did I skip a step somewhere? Perhaps I didn't download the right libs from MS? Or maybe I have to manually include a Reference to something? Any ideas?
Related
I am using a command line tool (ng-xi18n) to extract the i18n strings from an angular 2 app I wrote. The output of this command is a messages.xlf file. Coming from a .po background, and being not familiar with .xlf, I assumed that this file is the equivalent to the .pot file (correct me if I am wrong).
I then assumed that if I want to translate my app, I had to cp messages.xlf messages.de.xlf to have a copy (messages.de.xlf) of the template file (messages.xlf) where I can translate each message into German (hence the .de.xlf).
After translating some dummy texts and running the app, I saw that it worked as expected, so I quit translating and continued developing the app. After some time, I added more i18n strings, and eventually thought that I had to update my template. And this is where things got hardly maintainable. I updated the template messages.xlf file, and quickly was wondering how I could update the new strings to my already translated messages.de.xlf file without loosing my progress.
When I was developing using .po files, this was no problem thanks to good tools like poEdit, but I didn't find anything comparable for .xlf. After trying some tools, I thought that the best choice would be Lokalize, but I didn't find a possibility to merge the template file to already translated (but outdated) files either.
Up to now, this was rather an essay than a question, so here's a quick summary:
Is the workflow of dealing with .xlf files really comparable to .po as I initially thought (described above), or is it completely different?
How am I suppose to update my already translated files?
What are the best practices dealing with .xlf files?
What are proof of concept tools to work with .xlf?
Sidenotes:
The Lokalize handbook was not helpful at all. I see a lot of functions that sound promising, like:
"File" > "Update file from template". I did not find anything in the handbook to explain this function. If I click on this, nothing happens.
"Sync" > "Open file for sync/merge". This seems to be a function to merge two similar files (by multiple translators) rather than a tool to update the translation file from a template. Even though there is a tooltip in Lokalize's primary sync tab, notifying me about "x unmatched entries", I just couldn't find anything to append those unmatched entries to my .de.xlf file.
[Update] Turns out, I had similar issues as in this question. After downgrading my version of Lokalize to the suggested one, many issues (including the ones mentioned in the question) disappeared. However, now the "Update file from template" option is greyed out, and I don't know why.
I also tried OmegaT, which does not work at all on my platform (Ubuntu 16.04).
[Update] Virtaal works great for merging new strings from a template, but the UI in general is very poorly designed...
Googling did not help, as every hit seems to be related to XCode or something.
Thanks for any help in advance, I really appreciate it
I wrote a small npm command line tool called xliffmerge.
In principle it does the same, that Roland Oldengarm does with his gulp tasks described in his blog article.
It is free and you can have a look at it at https://github.com/martinroob/ngx-i18nsupport#readme
The best workflow automation solution I have seen described so far is from Roland Oldengarm's blog entry "Angular 2: Automated i18n workflow using gulp". To summarize, in a few dozen lines of Gulp code he created the tooling to handle some of the challenges you faced. Specifically it runs ng-xi18n to extract the messages; creates an English translation with sources copied to targets; updates existing translations by adding new trans-units, keeping existing ones, and removing missing ones; and then exposes all xlf files as TypeScript string constants. These last strings can then be imported to supply the bootstrapModule with its translation provider options.
Caveat: I have not used this exact solution (and code) myself, but I was able to expose generated xlf as TypeScript strings and use them in an app in a manner similar to what he described. As for maintaining translations, I have leveraged IntelliJ IDEA (WebStorm) file comparison features and Counterparts Lite (for Mac) for that. My own efforts are still in early stages but are working end to end for an application that is in active development.
Official Angular docs are now updated for Internationalization (i18n) at https://angular.io/docs/ts/latest/cookbook/i18n.html including a section specifically for creating a translation source file with the ng-xi18n tool.
I've got an old legacy application for communicating via serial port to an embedded controller communications bus. that someone else developed.
The application is written in VB6, and is structured as two projects - a DLL to handle the connection and communications logic, with an application GUI project.
I was hoping to be able to write a new application GUI (in C++ ideally) to use the existing DLL as-is, but I'm having lots of problems working out how to import it.
So I'm wondering, is it even going to be possible to use this old DLL into a C++ project as is? or is it possible to import into a C# project? or a VB.NET project? (would prefer not to use VB, but can if I have to)
Where I am now:
I have the existing compiled executable and DLL, and these run on my system.
I also have the project files, and they're all readable in notepad++ but I don't have VB6, and importing the project into visual studio VB.NET 2008 express isn't at all straightforward. Especially not without a working example to dig through and play with first (DLL project may be importable, but has 50+ things indicated as needing changing in the upgrade report. It also seems to be ignoring three .cls files that look very important to my not particularly VB6-savvy eyes... The application project has a message in the upgrade report about something "missing a design time license" and the only project files that actually seem to come into the project explorer for imported project is the project file itself, and the assembly info file.)
Most examples of how to import a DLL into VS C++ assume you have a solution with the DLL project all compiling nicely alongside your project that will use it. Or at least a .DLL and .lib and .h file... I spoke with the original developer of the code (in another city, we don't work directly) and got a .lib to match my .dll, but still have no .h file.
I'm usually fine to bash through something new, but without a baseline working example of the project even in VB6 that I can get my understanding from, it makes this very hard. Also a lack of similar questions anywher google can find them on the net makes me wonder if this is something i should be even attempting.
I'm working on getting a non-express copy of visual studio if that will make any difference (express worked fine for everything up until now so I never needed anything more) but that will take a number of weeks, most likely.
Any suggestions would be very much appreciated.
thanks for reading!
I have to disclaim this as I have no experience doing it, but merely found that it should be possible given some reading of the docs on the subject.
I'm not sure you'll have much luck with the VB to .NET import/conversion process if there is a lot of low level stuff going on. The existing dll is likely a COM object, no?
It seems like there is some MSDN documentation to get you started from C++ using COM object dlls - and it looks like the #import directive will generate some .h (header) files as well.
http://msdn.microsoft.com/en-us/library/8etzzkb6.aspx
So I would try simply adding an #import directive for it.
#import "somelibrary.dll"
and see what visual studio generates.
Have a look at the following example as well, (copied shamelessly from another forum)
#import "F:\proj\VB6\ActiveXDLL\VBTestDLL.dll"
using namespace VBTestLib;
void CDialogTestDlg::OnButton1()
{
HRESULT hresult;
CLSID clsid;
_CTest *t; // a pointer to the CTest object
_bstr_t bstrA = L"hello";
_bstr_t bstrB = L" world";
_bstr_t bstrR;
::CoInitialize(NULL);
hresult=CLSIDFromProgID(OLESTR("VBTestLib.CTest"), &clsid);
hresult= CoCreateInstance(clsid,NULL,CLSCTX_INPROC_SERVER,
__uuidof(_CTest),(LPVOID*) &t);
if(hresult == S_OK)
{
bstrR = t->vbConcat(bstrA , bstrB);
AfxMessageBox((char*)bstrR);
}
}
I'm responsible for maintaining legacy VB6 code, and have encountered an annoying problem with regard to the locking of a project's COM DLL. (We'll call it MyProject and MyProject.dll)
When I load MyProject into the VB6 IDE, I am able to compile the resulting binary-compatible DLL MyProject.dll. I can then run my (Classic ASP) web application that hooks into the DLL (or anything else for that matter).
So, when I try to recompile the COM DLL, I get a 'permission denied' error. I then find myself having to carry out the following steps in order for the DLL to be unlocked:
Check I have no dependant projects open in other VB6 IDEs
Recycle IIS
Check the file isn't read only (sometimes it will be if I have checked it in to source control)
Close the project and reopen it.
Often it is the last step that fixes the issue, and allows me to recompile, which means that the VB6 IDE is actually locking the DLL of the loaded project!
My colleague explained to me that it was to do with the way a VB6 project works with binary compatibility upon the DLL, but was unable to suggest a resolution.
My searches elsewhere have yielded very little in the way of answers. Search queries that are related to this tend to return a lot of unrelated answers (maybe I'm asking the wrong thing of search engines).
The closest thing I could find on Stackoverflow was this question from a couple of years ago, but it doesn't really fit the bill.
Does anyone have any other suggestions that might ameliorate this?
Keep a copy of MyProject.dll named MyProject.cmp and point binary compatible setting to your .cmp file. This way you won't need reopening project file (step 4).
During check-in you can mark keep checked-out to skip step 3 too.
I have 2 .net dll's which I expose to COM using REGASM. In order to simplify referencing within a COM client I would like to make these into one file.
I have tried converting both files to IDL and then copying the contents of the Library section of one into the other and then compiling back to .tlb with MIDL. This works fine for the TypeDefs within the second IDL however it seems to fail when it comes to the interfaces I copied in. OLE/COM viewer can see the interface definitions but when I try and use the TLB via COM it cant find the interfaces that I copied in.
I wanted to make sure before I spend too much time on this, that it is actually possible to meagre IDL's in this way.
Could you use ILMerge to first combine the .NET assemblies and then use REGASM on the resulting assembly?
ILMerge is a utility for merging
multiple .NET assemblies into a single
.NET assembly. It works on executables
and DLLs alike and comes with several
options for controlling the processing
and format of the output.
I don't see an obvious way this would fail. You said you merged the library sections but you didn't say you copy-pasted the interface declarations from the other .idl. That would be an obvious, but unlikely, explanation.
One failure mode is when the client app uses the type library to marshal interface pointers across apartment boundaries or out-of-process. That however requires registry keys in HKCR\Interfaces. .NET doesn't create them, you'd have to do that yourself. You'd know if you did, not much of an explanation either.
Ok so it turns out that the issues I was experiencing were not related to merging the idl's.
If you wish to merge to idl's you can do so by simply copying the content of a library section in one idl into another. Then run midl on the merged file to turn it into a tlb.
I know there are many questions out there regarding this same information. I have read them all, but my brain is all turned around and I don't know which way to go. Plus the lack of documentation really hurts.
Here is my scenerio. We are trying to use WIX to create an installer for our application that goes out to our dealers for our product information. The app includes about 2000 images and documents of our products and a SQL CE database that are updated via Microsoft Sync Framework. The data changes so often that keeping these 2000 as content files in the app's project is very undesirable. The app relies on .NET Framework 3.5 SP1, SQL Server CE 3.5, Microsoft Sync Framework 1.0 and ADO.NET Sync Services 2.0.
Here are the requirements for the app:
The dealers will be given the app on a CD every year for any updates (app or data updates).
The app must update itself from the internet to get any new images, documents or data.
The prerequisites must be installed if they do not exist on the client machine.
The complete installer should be generated from an MSBuild script with as little human interaction as possible (we don't want to be manually updating the 2000+ file list).
What we have accomplished so far is that we have a Votive project in our solution. We have manually specified the binaries in a .wxs file. Web have modified the .wixproj file to use the HeatDirectory task to gather our data (images and documents and database) from a specified location (This is broken and giving an ICE38 error). This seems all right, but still is a lot of work. We have to manually update our data by running the program in release mode and copying it to the specified directory.
I am looking to see what other people would do in this situation.
How would you arrange your solution with regards to the 2000+ data files? Would you create a custom build script that gets the current data from the server or would you include them as content files in the main project?
How would you get WIX to include all of the project output (including the referenced assemblies) and all of the data files? If you have any complete samples, that would be great. All I have found are little clips here and there and not an entire example from start to finish.
How would you deal with the version numbers? Would you put them as a constant in the build script and reference them through the $(var.VersionNumberName)? Would you have the version number automatically picked up from the project being deployed? If so, How?
If there is any better information than what I am finding, please include. I have read numerous articles, blogs, Stackoverflow questions, the tuturial, the wiki, etc. Everything seems to be in bits and pieces. The tutorial is nice, but doesn't explain anything about MSBuild and Votive. I would like to see a start to finish tutorial on using MSBuild and Votive and all the WIX MSBuild targets. If no one knows of a tutorial like this I may put one together. I have already spent the entire week gathering info and reading. I'm new to MSBuild as well, so if anyone has any great articles on MSBuild, please include them.
The key is to isolate the different types of complexities into separate merge modules and put them altogether into an MSI as part of the build. That way things that change often can change without impacting things that hardly change at all.
1) For the data files:
We use Paraffin to generate the WiX and hence the merge modules for an html + Flash based help system consisting of thousands of files (I can't convince the customer to go to CHM).
Compile these into a merge module all by themselves.
2) Assemblies: assuming that this is a set that changes less often just make a merge module by hand or with WixEdit with the correct files and dependencies.
3) For the version number there a lot of ways to manage this depending on your build system. The AssemblyInfoTask is pretty straight forward way to make sure all your assemblies are versioned appropriately. The MSBuild Extension Pack has some versioning stuff if you are using TFS.
I had a similar scenario and was unable to find a drop in solution so ended up with the following:
I wrote a custom command line program called wixgen.exe for generating wxs manifest files. It is pretty specific to our implementation in that it only knows how to create 2 types of wxs files. One for IIS Website/Virtual Directory deployments and another for Windows Service deployments.
Each time a build is triggered by our continuous integration server a post-build task runs wixgen with the right args to generate a new manifest.wxs for the project being changed. It automatically includes all the files needed for the deployment. These builds also version the dlls using a variation of the technique at: http://richardsbraindump.blogspot.com/2007/07/versioning-builds-with-tfs-and-msbuild.html
A seperate build which is manually triggered is then used to build the wixproj projects containing the generated wxs files and produce the msi's.
I would ditch the CD delivery (so 90's) and got with ClickOnce. This solution seems to fit well since you already use the .NET framework. With ClickOnce you should be able to just keep updating the content of your solution and make updates available to your heart's content. Let me know if you need, sample ClickOnce deployment code.
You can find more ClickOnce information here.
Similar to dkackman's answer, you should seperate your build into several components, isolating build components to be built seperately.
I come from a mainly Java background, however for building MSIs and NET executables we use maven; with the 'maven-wix-plugin' plugin for building the installers, and using the NMaven plugin for compiling any NET code. However, as we're only performing very basic development in NET, with most development in Java, we don't need too much complexity from the NMaven plugin (which is probably a 'good thing' (TM) as it's only at version 0.17).
If you're a purely NET house, you could also look into Blydan (http://www.codeplex.com/byldan), which seems to be the focus of development there at the moment (it's the same team for NMaven and Byldan).
If you do want more information on NMaven or Byldan raise another question and I'll give as much info as I can (which is not a huge amount, as stated I only do very limited NET development).