I want to create an IDE. I have an Isolated Shell application with VSIX Project for IntelliSense, and another VSIX Project for Syntax color. In the Isolated Shell application, I want to add a template, if that's possible.
I have the example of IronPython VS2010 Isolated Shell, but I don't understand how it works very well. In my work I have the language done with ANTLR, and for that language I need to create the IDE.
I know there are many questions, and I don't know if I could explain well, but any questions or assistance, or if you can refer to somewhere that provides this information, I would appreciate it.
Related
I decompiled the dll that my app creates for publishing it and found out, that everything is easy to read. The app is not rocket science but I'd like to hide some things, e. g. there are constants that are called productionHourlyRate what no one should know.
I know, there are obfuscation softwares but they are expensive.
An easy way would be to rename all variables and methods before publication, e. g. productionHourlyRate -> v1. Is there a built in possibility to do (and undo) this in Visual Studio 2022. Of course, I could rename them one by one but this is not very comfortable.
Or: Is there a free obfuscator that makes dlls undecompilable? No matter which tool I read about, I always find comments like "I decompiled the obfuscated dll with xyz and received the whole source code.".
Many thanks, Philipp
Edit: It is a C#/.Net app (Blazor WebAssembly)
Since there was no answer to this question, there is probably no Visual Studio built in solution.
So, I created an Excel tool that renames alle class, method and variable names in the specified files. Please find it here.
Important:
Make sure, you run this obuscator only when using a version control tool. You CANNOT undo the obfuscation with this Excel tool.
Usage
Add file paths in worksheet "files".
Run macro "Obfuscate" to obfuscate class, method and variable names with "v1", "v2"…
Publish your app.
Undo the changes with your version control tool.
Once all files are manually listed, the obfuscation should only take a few seconds.
I thoroughly enjoy the amazing power of LINQPAD (thanks, Joseph Albahari!) and particularly LINQPad's Dump method. Frequently I take an existing Visual Studio project and move it into LINQPad for the sole purpose of adding a couple Dump statements to see what the data looks like--though Visual Studio's data popups are certainly useful, the Dump output is just much easier to digest. To do this, I open each file I need from the current project, copy and paste the individual classes over to LINQPad, add assemblies and using statements, attempt to run so that LINQPad will tell me what I missed, and repeat until I find all the orphan references.
This method seems antithetical to the elegant, streamlined nature of LINQPad. Is there an easier way? Any chance of seeing "Import Project" on LINQPad's File menu any time soon? If not, I may end up writing a utility myself...
If you just want to call .Dump() in VS, check out this:
http://code.google.com/p/linqpadvisualizer/
Importing an entire VS project into LINQPad might be impractical... but I'm going to look in to whether just references can easily be copied over from a .csproj.
LINQPad is awesome and I also manually import projects occasionally. I haven't heard Mr. Albahari mention anything about "Import Project" functionality. And I'd be surprised if he would be interested in implementing something like this anytime soon.
Of course, he is very receptive to suggestions so I recommend posting your idea in his Nutshell forum which he frequents.
Additionally, check out the TypeSerializer in Service Stack libraries. I believe its Dump extension method is wrapped by LINQPad's which then encodes the output in XHTML. It might just be easier for you to use it directly in your code.
I've inherited some C99 code that I'm planing on reusing in a C++-centric solution. Unfortunately, even Microsoft's latest compiler has virtually no support for non-trivial C99 features.
The code in question has been tested to death and I'd rather not go through the trouble of rewriting it in C++. This means that in order for me to reuse the code verbatim I'll have to rely on a conforming 3rd-party compiler.
After looking around, it appears that the nicest way for me to integrate this code is by adding a "Makefile Project" to my solution. Only one problem. It seems like it is now my responsibility to keep the "Build Command Line" property synchronized with the files that I add to the project through Visual Studio.
At first glance, I couldn't find a way to get a list of files in my project through the usual Visual Studio $()-style macros. I could always write a shell script that would enumerate *.c files in my source tree and pass their paths to the 3rd-party compiler. However, I kind of expected that Visual Studio would do at least that part of the work for me since it already has this information in the relevant *.vc[x]proj file.
It is very unlikely that I'll need to add any new source files to this project, but still, manual synchronization (i.e., without a script) of this sort seems rather fragile to me.
What are my options besides writing a helper script?
From Hans Passant:
"Makefile project" means what it says,
there needs to be another 'agent'
that's responsible for the
dependencies. Like a make file. Rule
files can help you select another
build tool but that's kinda broken
right now in VS2010. Leverage the
original tool that built this C99
code, run it from the makefile
project.
There are lots of tools for creating installers on Windows (InstallShield, InnoSetup, NSIS, just to name a few). All tools I've seen fall in one or both of these categories
Point-and-click. Nice GUI for creating the installer, but the installer definition/project file can not be manually edited.
Textfile: No (official) GUI. The installer is compiled from a definition in a text-file which is manually edited.
The installers I'm building are all defined using a DSL (represented as YAML files), so using a GUI is out of the question, and creating is textfile is cumbersome although doable.
What I really would want is a tool which exposes a (complete) API, through which I can control the creation of the installer. Are there any such tools out there?
Edit: I'd love to hear about non-MSI based tools as well. MSI is not a requirement (rather the other way around...)
Wix 3.0 beta has .NET support included for this purpose. I don't know how well it works but it includes documentation. It's a framework of types for manipulating the installation creation process and all that goodness, so I don't think you even need to write a line of WiX XML if you don't want to.
WiX is a great tool, but you will have to do a lot of direct coding in order to make things happen. Fortunately the documentation is pretty good and there are several GUI tools, such as WixEdit on SourceForge to aid in the process.
Well, there is the Windows Installer API which you could use to create MSI files directly, however I think you'd be better off using WiX.
The "direct coding" will be much less than dealing with the Windows Installer API directly, I'm guessing that's probably going too "low level" for what you need. Depending on what you're looking to do, you could use WiX to generate an MSI and then tweak that afterwards using the API.
What's wrong with generating XML? That's really going to be your simplest option... you won't need to manually edit it, just write your own code to generate the required XML from your DSL files and a few templates.
I'd like to create a script that will configure the Visual Studio IDE the way I like it. Nothing vastly complicated, just a few Tools/Options settings, adding some External Tools, that kind of thing.
I know that this can be done inside VS with Import/Export Settings, but I'd like to be able to automate it from outside of VS. Is this possible, and if so, how?
Edited to add: doing it from outside of VS is important to me -- I'm hoping to use this as part of a more general "configure this newly-Ghosted PC just the way I like it" script.
Edited again: the solution seems to be to hack CurrentSettings.vssettings, or use AutoIt. Details below.
Answering my own question, in two ways:
In VS2005/8, the things I mentioned (Tools/Options, External Tools) are all stored in the CurrentSettings.vssettings file, in the folder "Visual Studio 200{5|8}\Settings". This file is just XML, and it can be edited programmatically by anything that knows how to parse XML. You can also just paste a new vssettings file over the top of the default one (at least, this works for me).
The larger question of configuring a virgin PC. It turns out that not everything I want to change has an API, so I need some way of pretending to be a user who is actually sitting there clicking on things. The best approach to this seems to be AutoIt, whose scripting language I will now have to learn in my Copious Free Time.
An easy way is to use the macro recorder to do something simple, then look at the code it produces and edit it as you see fit.
On my machine Visual Studio stores it's local settings in a file called VCComponents.dat. Its a text file, so perhaps you could find a way of placing your settings directly in there.
The file is stored in my users local AppData\Local\Microsoft\VC folder