I lost the code I developed for one Outlook addin and the only file I have is the VSTO. Any software to decompile?
If the code is not obfuscated you may use reflector to decompile it. Reflector gets as input the dll (this is the vsto file) and shows you the source code.
The result is not 100% your code, but you get all your classes and almost all the structure of the project (depends on project structure).
Look inside your Application folder (the folder you published your vsto file) for a file called YourProgram.dll.deploy and then make a copy of it. Once it is copied rename the file to remove the .deploy and then look at the YourProgram.dll file with any .Net decompiler and you should be able to see your source code.
Replace YourProgram with your actual program name.
Related
I have a certain VB6 add-in which needs to recursively start .vbp projects one by one, modify properties and then save and close.
I cannot use Shell(app name) as it needs exe, but I want to open a .vbp project.
Is there any way to do so via code?
If I understand you correctly then what you are looking to do is to modify the various files of the vb projects which is just a case processing text.
As in, find the .vbp file for each project, parse that to find the .frm, .bas etc. files etc in that project and then modify those as necessary.
Open some vb files (.vbp, .frm, .bas, .cls) with e.g. notepad and you'll quickly get an idea of what you need to do
have a look at Visual Basic Command-Line Compiler
I need to include all the output from some of the programs projects in the installer... my question is similar to the one in this post: How to add a whole directory or project output to WiX package
However, I am afraid I don't really understand the answer given in this link. From all the reading I have done, I think I need to use Paraffin to do this. But is there a "start from the very beginning, how-to" resource for using paraffin?
I have read this page: http://www.wintellect.com/CS/blogs/jrobbins/archive/2008/12/22/paraffin-3-0-now-with-full-wix-3-0-support.aspx
and one of the posts mentions calling paraffin from a bat file. Is this how one would "use paraffin" in their installer? If it makes a difference, I have been using Visual Studio to work on this project, and am also not sure how to use command line from within Visual Studio. Does anyone have any resources for a very new beginner? Thanks.
I ended up including each .dll and .exe manually, since they don't change very often. It was fairly easy to format them in this style:
`<File Id="WhateverId" Name="NameToDisplayAfterInstall" Source="$(var.ProjectName.TargetDir)Filename.ext" />`
I used Excel to format a list of files quickly and easily. I put all of these File tags in the <DirectoryRef Id="INSTALLLOCATION">
tag.
I did figure out how to scrape all the dlls and exes from the project output by using Heat (not paraffin) and harvesting a directory, not a project. Harvesting a project yields only the main exe and dlls. The problem with harvesting a directory, at least in my case, is that I ended up with a lot of excess files, (like .pdb and .xml) that I didn't want.
Probably a question that has been asked before. Please guide me to any questions that might answer my question...
I have a VB6 .exe that calls a VB6 .dll. I would like to debug the .dll from the .exe code.
Any ideas on how to achieve that? It has been a very long time since I have played with vb6.
Thanks
Open both VB6 projects in one VB6 IDE (a VB Project Group ... creates and uses a file extension of .vbg if I remember correctly). Also, set debugging to Break in Class Module.
You need access to the DLL symbols (usually a PDB file). Make sure that the dll symbols are being generated.
If you open the dll as raw text and go to the end of the file, you can find the path where the pdb file is expected to be located.
I think you have to add the dll project to the to the exe project (File->Add project) to step into the dll code.
Update:
Yes, I think you'll also need to remove the reference to compiled dll.
I'm facing a similar issue and I have been following all the steps you have provided. Nothing is moving. I'm not winning.
I think you have to add the dll project to the to the exe project (File->Add project) to step into the dll code. You'll also need to remove the reference to compiled dll.
In my C# client application, I use XSLT to transform XML into HTML.
I would like to be able to edit these files in place, without having to recompile the entire solution. I'm having trouble working out how to set up Visual Studio 2008 to allow this.
The problem is that the XSLT files must get copied to the output directory somehow. Currently this happens during the build process. (My XSLT files are set to "copy if newer".) The build process can take a few minutes, which seems excessive for making small tweaks to the HTML.
I could make my XSLT edits in the output directory itself, but the output directory is not under source control. I have accidentally wiped out my quick edits several times by building my solution.
I'd like to reduce the cycle time for debugging XSLT, while keeping my XSLT files under source control and preventing accidental overwrites.
Summary of Responses: It appears that the most practical approach for solving this problem -- given that Visual Studio doesn't have a nice way of doing it out of the box -- is to create a separate project that contains the content files. These files get copied to the output location when the project gets built. That way I don't have to compile the whole solution, just the one project with all the static information like XSLT, CSS, images, etc.
Several folks suggested using sync or batch copy tools, but while this would work for me personally, setting it up for the other members of the team too would be a lot of extra work.
I am not entirely clear about your question, but you can instruct Visual Studio to copy the file from the solution to the output folder every time that you build.
Let me try to understand your scenario:
You have the XSLT files checked into source control along with your C# code. For example, if your project is in a folder called MyProj, then the XSLT files reside in MyProj/Templates
You want to be able to edit the xslt files in the Templates folder and submit those changes to source control just like you do with .cs or other files in your project.
You want a copy of your xslt files in the bin/Debug or bin/Release folder along with your executable.
If that is the case, add the XSLT files to your Visual Studio project. Then right click on them, open Properties, and set "Build Action" = "Content" and "Copy to Output Directory" = "Always". Whenever you build your project, the latest copy of the XSLT files will be placed in your bin/Debug or bin/Release directory.
One approach is to include a C# Preprocessor Directive to point my XSLT load function to the solution directory when in debug mode, but the output directory when doing a release build.
Something like:
string viewFolder = AppDomain.CurrentDomain.BaseDirectory;
#if DEBUG
// Move up from /bin/debug
viewFolder = viewFolder + #"..\..\";
#endif
But that feels like a hack.
Apparently you're managing two concerns in one project. The first concern is your business logic (instantiating an XSLT transform, calling it to transform some XML content, outputting the HTML result....). The second concern is the Transformation itself.
So why not create a separate project for your xslt sheets? "Building" this project would consist of copying the sheets to the output folder. Changing xslt will not influence the other project, hence reduce the build time.
Separation of Concerns at project level, that is :)
You can edit the file directly in the output folder.
On another note, a lot of people don't know that rich tools are built into VS to allow debugging xslts.
http://msdn.microsoft.com/en-us/library/ms255605(VS.80).aspx
One solution that might work for you is to setup a junction to your Templates in your output folder. This would allow you to use the XSLTs directly without copying them to the output folder. A good idea is to ensure (create) the junction as a build action.
Prerequisites:
NTFS
A tool to create junctions (e.g. junction)
Create a batch file that copies your xslt's from their source-controlled location to all your bin directories (bin/debug bin/release or whatever ones you have defined)
Add the batch file as an External Tool, optionally assigning a keystroke (or chord) to execute the batch file
Edit, run tool (I'd assign a keystroke to this to make this easy), then check your webpage.
Could you use a file synchronization program (e.g. Microsoft SyncToy "is a free application that synchronizes files and folders between locations") to copy the files? This would allow you to avoid the "copy on build" step because the files are automatically copied after saved. Also, if you edited them in the output directory, the changes could be copied back into your source controled directory. Not what the best real time sync program is for this scenario is, but that could be another question.
I have exactly the same issue. I have bought a program called ViceVersa (http://www.tgrmn.com/) in which I have setup sync profiles so that my css, layout and xslt folders are synced from my machine to my dev server as soon as any changes are made. If I make any code changes then I just publish as normal.
I understand this is an older post but I found a different solution to basically the same problem.
Visual Studio allows you to 'link' files.
Right click on the folder in the solution where you want the file link to be located.
Click
'Add'
'Existing Item..'
(select the file)
Go the 'Add' Drop down and select 'Add as Link'
I need to add a C# solution with examples that would be distributed as part of a software library installer. This solution would have various examples on how to use the product's API.
I want to be able to display a simple "quick start" file explaining how to run the examples when the solution is opened in Visual Studio.
Is there a way to tell Visual Studio to open a specific text file when the solution/project opens?
It sounds like a solution or project template would be the best option. This would let you create an entry in the user's File - New dialog (Similar to 'New Class Library" etc). In VS 2008, these are easier to create - File -> Export Template. The template is just a zip of the project(s) with an xml manifest file you can modify. Part of the manifest schema allows you to specify files to open as HTML or text. The templates can be installed relatively easily as part of a installer package.
Here's more on the general concept:
http://msdn.microsoft.com/en-us/library/6db0hwky.aspx
And schema reference about how to open files in various modes on startup:
http://msdn.microsoft.com/en-us/library/ys81cc94.aspx
If you need to provide more guidance/wizards, consider Guidance Automation Toolkit.
What Will said.
The UI state of the solution (e.g. which files are open for editing) is stored in one of the solution files of which there's supposed to be a separate copy for each user, and which therefore isn't usually checked-in to the shared version control: i.e. not the *.sln file but instead I think the *.suo file (but beware, this is a binary file which won't 'merge').
I don't think it is possible to have a solution file open specific content or even script actions, actually.
Perhaps you could create an MSI setup for your library (if you haven't already) and not deliver a solution with example code, but a project template that is installed by the MSI in the right place to be instantly available as a template in VisualStudio? Then someone can easily do "New Project", select the demonstration template and get a project preset with your example code.
Just make a .bat file (using the VS env) with that calls devenv /useenv yoursolution.sln - this way you can make things a bit fancy if you want to ;)