I have been working for quite sometime to transfer all of the installations for my job from Wise for Windows Installer to WiX. Started with the obvious step (given the number of installations to transfer and their size) and decompiled them with Dark.exe (WiX toolkit). I have been creating a general purpose program to clean up the output from dark into a proper project that we can then compile into MSI's. The problem that has been kicking my #$$ for some time now is the merge modules. We have a maximum of 20 Microsoft MSM's in the various installations, and dark doesn't recongnize these as such so instead lists all the contents. I have everything in place so I can erase this garbage code and replace it with the proper Merge tag. Hence the problem. The merge modules don't have any rhyme or reason to where they are placed, no logic I can find to look for the main folder. The only real common ground is that the Directories, Components, Files, and Registry tags all have an Id ending with a GUID. Any ideas would be greatly appreciated. I already have the frame work in place to search through our list of Merge Modules and retreive the list of files, components, and directories. I just don't know what to look for so it is not speciallized to just one or two modules, but in theory all MICROSOFT modules (I know other companies might use other formats, but that is a mute issue). Thanks again!
It looks like you have been doing a lot of work reverse engineering the existing MSI's and cleaning up the result in an automated or semi-automated way.
Wouldn't it be more efficient and less error-prone to just create the wix source files from scratch? You might be able to leverage the heat.exe tool to reduce the required effort.
Related
I am trying to create a tool using c# to get the properties generated from clicking through the dialogs of an msi(windows installer).
I can get the final msi properties by reading the _property table before the msi closes but this contains quite a number of properties that are not required e.g. directories etc.
What i would like to be able to do is just launch the dialogs and get the populated properties relating to those dialogs. Could someone point me in the right direction?
Thanks
B
In the interest of helping, and since nobody else has answered, I will just write what I know, though it isn't really an answer in a technical sense.
There are several tools available that already do this - some even used to be free but the downloads were removed (Wise InstallTailor).
I don't know what your use-case really is. If you just want a solution for a specific task, or you are intending to code this yourself despite other solutions being available?
Wise Package Studio had one transform generator called InstallTailor. I don't think it is freely distributable as the product has been taken off the market and bought up (or we could have shared the EXE - it used to be freeware as far as I recall).
InstallAware has a feature called InstallAware Transformer:
https://www.installaware.com/installtailor.htm
Advanced Installer has a feature to create a "Response Transform" which is essentially doing the same as InstallAware transformer with slight variations.
Installshield has a transform project type which offers pretty much exactly the same features as the other two products by the looks of it.
The above are all commercial products, but some of these features may work after the trial period has expired. I cannot guarantee it, but it looks like Advanced Installer allows a response transform to be generated freely.
So that is a non-technical answer for you. Perhaps you just need to get a tool to do the job?
A few months ago a developer pushed and merged a feature branch into our main branch (develop) that contained test files (800MB). I deleted these files from Bitbucket and everything (it was a pain). Now I am looking for a solution that could prevent this from happening in the future.
Is there some kind of process/script that I could run before performing a merge to my main branch? I would like this process to check every single file in the solution and verify that every file is less than 2.00MB.
Not sure if this will help or not, but the solution consists of various C# projects, including unit tests.
Use one of the git hooks to prevent this, either on receiving a push in the central repo, or before merging.
Having a server that other devs use, I currently log the version of the dll they use. I do that by having the client that use Reflection to retrieve its version:
Assembly.GetEntryAssembly().GetName().Version.ToString();
It's nice, but since it come from dev that uses TFS and do themself the build, I can not see if they have the latest version of the sources. Is there a trick, like a compilation tag, that would easily allow a hash of the generating source code?
Note: I have try to send the MD5 of the dll (using assembly.Location), but it is useless since the hash value changes between 2 compilations (I suppose there is some compilation timestamp inside the generated dll).
This is most collaboraton issue then a coding.
In the moment that you find out that the version is old one.notify them about it.
If the real version is not old one, that means that developers before making buold did not increment the version ID, which is mistake.
In other words, ordanize it among people, and not relly on these kind of tools (if there is any). You trying to create a complicated tool, that will help you avoid mistakes, but humans will find a way to make them again.
So it's better to create solid relation structure among you, imo.
Create a tool on pre build event to hash/last-write-time your code files.
Write the result to a cs file or a embedded resource file.
The result file must exclude in above action.
For prevent skip build (up-to-date) feature not work,Compare the file before write.
And if youre opening the file in IDE will get a prompt `changed from out side' when build.
Seem there is no easy way to do it.
We have a program that is used in one specific industry and has strings that are specific to that industry. We now have the situation where it can be used in another industry and we want to customise the strings for that industry without duplicating our code base.
The problem space appears very similar to localisation. Are we going to have a separate resource assembly for each industry? If so when would we choose which assembly to use, could we do this at install time or would it need to be at compile time?. How do we keep the separate resource assemblies synchronised, so that the same keys to messages appear in each one?
What is the best way to do this?
Let me re-phrase it: you have an industrial application which could be used in various industries and the only things that are different are resources (that is strings, layout, maybe images and sounds). The other code stays the same.
In such case your problem is not just similar it is actually identical to Localization. And as such you can use Satellite Assemblies.
Now, it is up to you if you want to package such created applications separately or distribute one application with both problem spaces.
The first seem more realistic scenario to me - you would need to decide on which .resx file to include at compile time (i.e. during project preparation you would overwrite existing resources with problem-space resources and then proceed with compilation, that should give you different flavors of your application; I would also modify their names in such case).
The latter would require you to manually instantiate ResourceManager at runtime to read from valid satellite assembly - it could be based on some configuration file. It means more work (you would need to actually modify your code) and you will end up distributing both flavors of your application at once, that is you won't have control over how your customers will use it. From the business perspective it could be a little dangerous.
EDIT (Note to self: read whole question carefully)
Somehow I managed to miss install time vs. compile time. I believe compile time is the answer because of the same reason I gave in config-driven switch section: you would package the resources and you won't have any control on how customers use it. Some clever guy would figure it out, that is for sure.
I would recommend having a properties file with key value pairs. Where you currently have industry specific strings, replace them with calls to the properties file. Obviously you would cache these strings in some container. I don't know the C# container - Java would use java.util.Properties.
aerospace.props:
INDUSTRY_NAME=aerospace
INDUSTRY_START_YEAR=1903
manufacturing.props:
INDUSTRY_NAME=manufacturing
INDUSTRY_START_YEAR=1600
i am creating my own CMS frame work, because many of the clients i have, the have same requirements, like news module, newsletter module, etc.
now i am doing it fine, the only thing that is bothering me, is if a client wants to move from my server he would ask me to gibe him his files, and of course if i do so the new person who will take it he will see all my code, use it and benefit from i, and this is so bad for me that i spend all this time on creating my system and any one can easily see the code, plus he will see all the logic for my system, and he can easily know how other clients of mine sites are working, and that is a threat to me, finally i am using third party controls that i have paid for their license, and i don't want him to take it on a golden plate.
now what is the best way to solve this ? i thought it is encrypting, but how can i do that and how efficient is it ?
-should i merge all my CS files and Dlls in bin folder to one Dll and encrypt it, and how can i do that ?
i totally appreciate all the help on this matter as it is really crucial for me.
you should read this
Best .NET obfuscation tools/strategy
How effective is obfuscation?
In my experience, this is rarely worth the effort. Lots of companies who provide libraries like this don't bother obfuscating their code (Telerik, etc).
Especially considering what you are writing (CMSes are everywhere), you'd likely see more benefit from your time spent implementing features that put your product/implementation in a competitive advantage and make companies see that the software you are capable of writing has value, rather than the code itself.
In the end, you want to ensure you are a key factor in making software work for a company, not the DLLs you give them.
You'll need to precompile your site and obfuscate dlls.
Visual Studio has something like Dotfuscator Community Edition shipped with it. You could give it a try.
Of course, HTML output, CSS declarations, database structure and stored procedures code cannot be encrypted.
You can however try to compress CSS which will also reduce its readbility by humans.
Check here: The best approach to scramble CSS definitions to a human-unreadable state throughout an ASP.NET application
One other idea would be to use a frame in your HTML and put the most of the site pages inside of it. This way, it will not be visible when doing "View source".
Or just state it clearly that you offer whatever you're doing as a service and do not provide source codes of your work. I somehow doubt salesforce would be willing to give their sources to anyone who asks.