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?
Related
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.
Quite a few people have really taken interest in the dll's ivé sent them, and they're not the type that should be given away for free too often...
I was just wondering, if I were to sell my components, user controls etc, how would I go about protecting them, in terms of ownership/encrypting code (if possible) etc.. What steps have you taken to help prevent people using yours without paying for them?
You can use any commercial obfuscater which encrypt your functionality and giving error if decompile.
Here i have the whole list which are available in market.
I used many of them some are just encrypt string, public method, private methods,properties and all.
Just go through it.
see the whole list and article
The only truly secure way to protect your dll is not to give it to them. Expose it instead via a web-service etc (obviously this doesn't work in all cases). Every obfuscator can be broken with patience. Think how much the games industry spends on this, and things are broken / reverse-engineered within days, sometimes hours.
"Lawyers" may serve as a layer of protection, and obfuscation will certainly discourage idle browsing. But a determined hacker (for example, for commercial illegal spying) will be able to get at your code eventually.
I guess you simply need to weigh the costs and benefits...
Well, I will definitely put my copy right,company name and production name information to my DLL. Whenever anybody use it,those information still appear on my DLL. And if possible,I will try to use Dotfuscator tool from visual Studio which helps to obfuscate my DLL.
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.
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.
OK so that title sucks a little but I could not think of anything better (maybe someone else can?).
So I have a few questions around a subject here. What I want to do is create a program that can take an object and use reflection to list all its properties, methods, constructors etc. I can then manipulate these objects at runtime to test, debug and figure out exactly what some of my classes / programs are doing whilst they are running, (some of them will be windows services and maybe installed on the machine rather than running in debug from VS).
So I would provide a hook to the program that from the local machine (only) this program could get an instance of the main object and therefore see all the sub objects running in it. (for security the program may need to be started with an arg to expose that hook).
The "reflection machine" would allow for runtime manipulation and interrogation.
Does this sound possible?
Would the program have to provide a hook or could the "reflection machine" take an EXE and (if it knew all the classes it was using), create an object to use?
I know you can import DLL's at runtime so that it knows about all sorts of classes, but can you import individual classes? I.E. Say I have project 'Y' that is not compiled to a DLL but I want to use the "reflection machine" on it, can I point at that directory and grab the files to be able to reference those classes?
EDIT: I would love to try and develop it my self but I already have a long list of projects I would like to do and have already started. Why reinvent the wheel when there is already a great selection to choose from.
Try looking at Crack.NET. It is used to do runtime manipulation and interrogation on WPF/WinForms but the source is available and might be a good start if it already doesn't meet your needs.
It sound as if Corneliu Tusnea's Hawkeye might be close to what you're looking for runtime interrogation of objects/properties/etc. He calls it the .NET Runtime Object Editor. I'm not sure if the homepage I linked to above or the CodePlex project is the best place to start.
It's a bit out of date now, I think, but there's an earlier version of it on CodeProject where you can see the source code for how and what he did.
Powershell actually does nearly all of this, if I properly understand what you are saying.
See this answer on how to build a "reflection engine".
All you need to do is to drop that set of machinery in the your set of available
runtime libraries and it does what you want, I think.
(It might not be as easy as I've made it sound in practice).
My guess is you'll also want a runtime compiler, so that you can
manufacture instrumented/transformed variants of the program under inspection
to collect the runtime data you want. You may find that such
machinery provide static analysis results that let you avoid
doing the runtime analysis in many cases.