I'm writing an Eclipse plugin that needs to specifically make use of Workspace, Projects, Packages, Compilation Units etc.
I already have a decent number of projects, packages, and compilation units in my workspace (not all related to my plugin though, but present nevertheless), which I would like to be able to use as a 'test dataset' for debugging.
When I click the toolbar icon of my plugin, I can print to the console the names of the projects returned by this statement:
IProject[] projects = ResourcesPlugin.getWorkspace().getRoot().getProjects();
However, when I launch the debugger, a new Eclipse IDE instance starts up with no projects visible in it anymore. While no project is visible, the projects array does list the project RemoteSystemTempFiles!
But this is completely useless for my debugging needs, as I need some good data set to step through during debugging.
Question: Is there any way to make my projects existing in the development instance of the IDE appear in the second, debugging instance also? Or, if not, can I somehow debug in the same IDE instance instead of starting a second one? I would hate to litter all my code with console-log messages - it's very tedious also to write them in the first place. Setting up the existing test data in the plugin's initialization code would also be way too much work, which I would like to avoid as well.
No you can't run or debug in the same instance. Eclipse will always start a new instance.
You will have to set up the test workspace to contain the data you need to test with.
Related
Most of the time, when I build my project, I'm able to attach to breakpoints and debug, as I should. However, sometimes after building, I still get the error “The breakpoint will not currently be hit. The source code is different from the original version.” No matter how many times I build and rebuild it doesn't change it, until seemingly randomly it decides to behave and start working again. How can I fix this when it happens?
Edit: My builds are fine, there are no errors in my builds.
A wild guess...
In "Solution Property Pages" -> "Project Dependencies", choose the project and make sure the dependencies are defined well; for example: if you are using a web service in another project in the same solution, you should make the project including the web service depending on your project or you will not be able to debug the web service.
Of course, I don't know how this option may be bypassed as you say it happens to you randomly.
I'm writing a unified project for 3 smart TVs. I have also 3 configurations created in Visual Studio. Now I want to execute some CLI scripts depending on selected configuration.
The problem is in new ASP.NET 5 project I don't have an editor for post build events.
I know I have to do this in project.json. What I found is:
"scripts": {
"postbuild": ""
}
But using this one I can't create different CLI scripts for different configurations.
I found also:
"configurations": {
},
And I guess this is probably what I want, but... How to use it? Intellisense has no power here and also I wasn't lucky searching the Web...
[edit]
Maybe I should try with .xproj?
You'll need to build a master script which uses the available context and environment variables to switch and run the other scripts of your choice.
In addition to the list of variables Here for compile, you also get these for publish related scripts and then these are available everywhere, as are environment variables returned by Environment.GetEnvironmentVariable, which can be seen here.
The image below shows the intellisense from the VS2015 Update 3 RTM, but it's misleading, since you get others depending on the script block you're using:
So, your full list of context variables that you can use to control flow in your scripts is:
Every script block:
%project:Directory%
%project:Name%
%project:Version%
Compile specific:
%compile:TargetFramework%
%compile:FullTargetFramework%
%compile:Configuration%
%compile:OutputFile%
%compile:OutputDir%
%compile:ResponseFile%
%compile:RuntimeOutputDir% (only available if there is runtime output)
%compile:RuntimeIdentifier% (only availabe if there is runtime output)
%comiple:CompilerExitCode% (only available in the postcompile script block)
Publish specific:
%publish:ProjectPath%
%publish:Configuration%
%publish:OutputPath%
%publish:TargetFramework%
%publish:FullTargetFramework%
%publish:Runtime%
I investigated on this a bit but did not really get to any good result.
There are some project variables that are exposed in scripts. Unfortunately, those are very limited:
%project:Name% gives you the project name
%project:Directory% gives you the project directory
%project:Version% gives you the project version
So there is no way to access the build configuration or the environment here.
The configurations option in the project.json is also limited to build configurations and only allows declaring compilation options there, so that also doesn’t work.
Unfortunately, there also doesn’t seem to be another way to solve this. At least not right now. I would consider myself sending a pull request to DNX to add some additional project variables which one could use but at the moment, it doesn’t really make any sense to invest time into DNX: After all it’s being replaced by the dotnet CLI. We’ll see if that one will come with functionality to access the environment—and if not, I might end up submitting a pull request to add this functionality. But until we get there, I’m afraid there is no solution for this.
I have web config transformations set up that work fine when I publish to something like Azure. But selecting between Release and Debug locally seems worthless if the web.config transformations don't actually get applied when running locally.
Is there any way to get these transformations to apply when I click "run"? If not, what's the point of having that dropdown? I'm genuinely curious, not asking rhetorically.
The idea for web.config transforms is that you have some settings that change between environments. For example, you might have a local development connection string, and you'll always use that when running/debugging locally. When you publish to your production server, though, you want to use your production DB. Debug vs. Release configurations at build time just change some settings in how your project is built (most commonly, how debug symbols are generated or what compiler optimizations are enabled), whereas web.config transforms are changing the content of what gets deployed (in web.config).
If you do want to apply the web.config transforms locally on F5, there are extensions that allow you to do so. Slow Cheetah is one such. However, in many cases, you probably don't need this as your web.config will stay mostly constant whenever you run locally.
Almost all IDEs have release and debug modes, in the debug mode, the code is compiled using debug flags and not so much optimization, i.e., some relation between the built program and the source code is kept, in this way you can run your code using a debugger, it is a tool that allows you to track and control the flow of execution of your application, for example the value stored in some variable in some situation in your code, this in order to expose semantic problems that your application may have, i.e., when your code is not actually doing what you expect it to be doing (most of the people does this using print statements everywhere at least once).
The release mode is aimed to produce an optimized version of your application, without debugging/profiling flags.
Notice that this have nothing to do with debug mode of web applications, where we set automated views to show more information when a run time error occurs, it just have to do with optimization or debugging of the actual program running underneath. So setting debug or release mode may not change whether a web application shows tracebacks or not, but it certainly changes the performance of the application running locally in your server.
Regards.
I would like to simultaneously start multiple instances of a project using Visual Studio. By pressing F5 (Debug -> Start Debugging), at most 1 instance of each project in the solution starts, respectively. I didn't find a way to configure startup of multiple instances of the same project.
The project in question is a console app that is difficult to convert in a way to enable multiple instances within the project.
Well, if you are looking for simultaneously, I don't know.
But you can try right Click on the Project Debug -> Start new instance as many times as you like.
If you don't need to debug you can start multiples instances ("Start Without Debugging")
In case you want to debug an instance you could then attach the debugger to it.
If attaching the debugger is not an option you could use System.Diagnostics.Debugger.Break() method in your code. The equivalent but programmatically.
It's not possible to debug multiple instances of a project using a single project. The IDE/debugger need to synchronize program execution with source code and debugging symbols; it can't do that unless there's only one instance.
You could, however, copy your project multiple times and start them as you describe (as a solution).
Select and Right click any project. Then debug and Start New Instance
I am struggling with the purpose of the build configuration manager in Visual Studio 2008. Specifically I am interested in knowing what it does when developing a console application and also a web application (web application project). Does setting it to Debug or Release mode make any difference when you are developing and running the application in the context of VS2008? What does it to when you want to build the solution?
The Build Configuration Manager allows you to set different combinations of project build options for a solution. For example, say you have a solution with 4 projects, log4net, a DAL, a Business layer and the Website. Most times you'll want to run the website and business layer in debug, but the DAL and log4net in release mode. Sometimes you'll want to run the DAL in debug too, but only on a rare occurrence will you want to run everything in debug. The config manager lets you define configurations like that.
Additionally, you could define a x64 build that had some projects target x64 and others target AnyCPU depending on need. Or even a build target that excluded specific projects and included others depending on need.
So in short, the config manager lets you control the inter-process build relations at a level beyond the simplistic debug-all or release-all.
I'd also guess, that 99% of the time you won't need to mess w/the config manager anyway. :-)
I've found this tool incredibly useful in the following situations :
1- You have a lot of projects in a solution, and you want to build only the project you're currently working on (which takes 10s instead of 2mn)
2- You have to produce on a regular basis different type of builds (debug vs release, x64 vs x86, etc.)
To answer your question regarding differences between debug and release mode, it definitely makes a difference. Typically, VS will compile your code "as is" when building in debug mode, while it will optimize (ie inlining, etc.) things in release mode.
For example, if you build this code :
public bool Foo(){
return true; // put a breakpoint here, and move the execution position to the next line
console.WriteLine("Foo");
return true;
}
In debug mode, you will be able to do that , not in release mode (because the compiler has detected the code was unreachable, and hasn't build it at all.