I'm trying to develop an Application in .Net4, that creates a custom Window, inserts custom controls and saves it in a directory. My next challenge is how I can generate/build additional code from my Visual Studio Solution in a WPF .exe Aplication. I need only some classes that will be generated and transformed to a .exe. This classes will give the logic to navigate from one Window to another.
Here is a little diagram that I did for the question:
Things that I have researched:
CSharpCodeProvider: I can pass some classes in a string[] but I don't know how they will work with dependency, or when a error/bug occurs it will be difficult to see where the error is. And finally worst thing is that I can't set a location to build this .exe. It's built in the main Solution/Bin/Debug.
MSBuild: Here I can set the location where I will build the solution, but for this I need an extra Visual Studio Solution. What I'm trying to do is to have inside my Application a Build button that can build like in Visual Studio a .exe program but with custom classes that I will have in my Application.
I don't know if its possible, I was looking for it but I'm a little bit lost. I see in http://www.icsharpcode.net/opensource/sd/ that the have a builder, and they can set the location and build a .exe from the code. The only difference from SharpDevelop is that my controls and Window are customs.
UPDATE:
Maybe what I'm trying to do is better with other tools. Maybe compiling C# in runtime is not he best way. I will appreciate another ways to solve the problem.
What I do is Creating a new extra project for this .exe and must just copy/paste this .exe to each Project location.
But this is not very useful, if every time we must copy/paste this .exe
I just searching or a solution. I made this as a alternative solution but I don't like it so I will continue to investigate for a generation tool or something else.
Related
I'm writing a C# application that accepts plugins. The way I accomplished this is as follows:
In my solution, create a project that contains a single interface that defines the expected methods of a plugin class.
In the main application, add a reference to this project containing one interface.
Add a third project to the solution which represents a plugin. This plugin also has a reference to the interface project.
In my main application, I scan a plugins folder for files matching a given filename (plugin_.dll). If such files are found, I load the assembly and then use reflection to look for any class that implements the interface. For any such class, I add an instance of it to a List<IPlugin>. The app then has access to all the plugins via this list.
This works great and I have successfully written a couple of very simple plugins.
Here's where I'm struggling:
When I want to test the plugin, I have to first build the solution and then manually copy the built plugin into the correct location which the app scans. I know I can probably automate this by adding a post-build command though.
More importantly, is there a good way to actually debug the code in the plugin? (single-step, exception breaks, etc.) Right now I simply run the app and see what happens. I use extensive Console.WriteLines if I need to trace something. It's far less productive though than using VS's debugger.
Less important at this particular point but could be a thing down the road: how would someone else debug the plugin? More specifically: if I start a new VS solution and make a reference to the interface assembly, is there any reasonable way to debug the code in my new plugin?
For a game engine called duality (https://duality.adamslair.net/) I want to make a solution template that will create the necessary projects and all the files needed for duality to function. This includes files and folders that are not part of a project themselves.
In order to achieve this iam trying to make a wizard that can generate the files/folder structure I need as I understood that templates alone are quite limited in this aspect. I followed this tutorial: https://msdn.microsoft.com/en-us/library/ms185301.aspx.
However when I debug this and try to create the solution it says it failed but not why or how. Breakpoints are not being hit either since the symbols are not loaded.
This is the error I get when trying to create a project using my template:
When I comment out the WizardExtension node in the vstemplate it works fine
So how do I change my project so that it does load the symbols and I can debug it? Iam using vs2017.
Included is my project:
DualityTemplate
Turns out it was because the platform was set to Any Cpu. When I changed this to x86 it worked without problems.
This is most likely cause by the extension deciding to run in 64 bit while visual studio is only 32 bit.
I want to obfuscate a single .dll file (to hide constants). When I confuse .dll compiled as release for any processor AND application is started from .exe - everything works fine.
Unfortunately this .dll is meant to be a "key" for some things in our database that we want to give to someone else to use. But I don't want them to be able to recover this source code in like 2-3 clicks by DotPeek or any other reverse engineering tool for C#. They are still testing their things, so they start their app from Visual Studio.
When I add non-obfuscated .dll to my test project as reference - everything is fine. But when I add already obfuscated .dll as reference I get 'FatalExecutionEngineError'. And that's unfortunately the whole point - I want them to have this .dll for usage and testing purposes, but after obfuscation it may not be possible for them to use it from Visual Studio.
Am I doing something wrong or should I just use a different obfuscation tool?
I'm about to start developing a desktop application (WPF) based on a "plugin" architecture, and was going to use MEF (and its DirectoryCatalog) to discover and load plugin assemblies. We're going to be developing many plugins, so it seems sensible to keep them in separate VS solutions rather than bloat the "core" application solution, but having only ever worked on single, standalone solutions, I suspect this is going to make debugging a bit tricky. I'm using VS2013 if that makes a difference.
I'm assuming that I'll still be able to step into a plugin in scenarios where the "core" application calls a method in that plugin? And I'm guessing that once in there, I'll be able to set breakpoints in those source code files that have been "visited"? But what if I want to add a breakpoint to a different source code file - one that hasn't been visited while stepping-through? How can I open that file? In a single solution I could just open it via Solution Explorer, but not (I'm guessing) when it's in a separate assembly.
I'm trying to pre-empt any problems I might have with this multi-solution approach, and wondered if VS had any clever features to simplify some of this stuff. Having separate solutions also means first compiling the plugin solution(s) that I want to test, then compiling and running the "core" application solution. While it's only a couple of extra mouse clicks, are there (again) any VS features that could help here?
This is a common scenario and not tricky at all.
In the project properties of your plug-ins, go to Debug -> Start Action and set Start external program to the executable of your core application.
This way, you only have to compile your core application once (probably using a build script that just builds everything), and debugging a plug-in will start the core application with the debugger attached and you can debug the plug-in (as soon as your core apllication loads the plug-in assembly).
Also keep in mind that you can dettach the debugger from the running application, switch to another instance of Visual Studio with another solution opened, and again attach to your running application. This comes in handy if you e.g. debug your plug-in and want to set or use existing break points in your core application.
As long as Visual Studio is able to find the debugging symbols (the *.pdb files), stepping through the code of e.g. your core application while debugging your plug-in is also no problem.
I see two ways to do this.
The more comfortable option:
1. You can add the external solution to the core solution.
Walkthrough: Adding an existing Visual Studio solution to another solution
By doing this you can organize your solution to reference the code and still keep each plugin solution separate at the same time.
You just reference those plugin solutions from your core solution that you currently want to work on. Also, using this approach you can organize the other solutions just like you would with normal projects and move thembetween virtual solutios folders to your liking until you have the most adequate folder structure.
Quote from the article:
The nice thing about this approach is that not only are all the
projects now in one solution but at any time, you can open the
separate solutions without impacting the "master" solution and vice
versa.
The files in the references solution can be opened and edited just like any other file from your "normal" projects, and of course, you can set breakpoint like in any other code file, too.
This way you can both edityour code and step through it, which I personally find much more convenient than switching and attaching to multiple processes.
2. Add the PDB files.
Put the DLLs with their corresponding PDBs of those plugins you want to debug into a folder and configure your core application to use that folder for the DirectoryCatalog. This enables you to step into the plugin code, but you will not be able to edit them.
#Andrew
Regarding debugging, it shouldn't be an issue as long as you drop the .pdb files with assembly in directory which you are using as DirectoryCatalog.
Regarding building plugin solution before Core- as you have 1 build file for each solution, you should check if you can write msbuild commands in a .bat file to get it executed one after other.
Besides all the above suggestions, another way to debug is to attach your addin solution to the running core process. Attach to Running Processes with the Visual Studio Debugger
I have several class files in App_Code in an ASP.net website running in Microsoft Visual Studio 2005 Professional.
In liu of using a full unit test suite I just want to somehow compile those project-wide classses into an .EXE so that I can nightly run unit tests on them.
I do know how to create a separate C# library project consisting of those files and how to include them into my website--but that is not desirable--I don't want to give up the ability to make on-the-fly code changes of those library classes when running the website in the debugger. As far as I know .Net debugger isn't powerful enough to modify code in included libraries with instant auto re-compilation on page re-load.
So, I want my cake and eat it, too:
Command-line unit testing of website class files in App_Code directory
Being able to modify those class files w/o stopping/re-starting the web debugger.
Is it possible to have both?
You should put the code in an altogether separate class library/assembly, then reference it from your web project and the command-line utility. As far as I know, it makes no difference where you modify your code, when stopped in the debugger. Never had problems myself.
Hope that helps.
Your project is under source control, right? Right? In that case, you can use your source control system to include a link to your asp.net project's app_code folder as part of a separate unit testing project. The exact linking mechanism varies by source control platform, but done right it means there's exactly one instance of your App_Code folder in source control that's visible from two different projects. This way, everything stays up to date.
This has the advantage of allowing you to keep easy, uncompiled code right there just like you always have, but still making the code available for testing.