Hi,
Will it be possible to attach to remote processes ?
I have a .net core app running in a docker container and I would really like to debug that at some point.
Cheers,
John
it’s on the roadmap, yes.
Hi Marc,
Any update on this?
Regards
-Mohamed
It kinda fell off the priority list — but i’ll bump it up again and see if we can add this fairly soon. it’s not a big technical problem, it basically just has to be hooked up and exposed in the UI, i think.
Thanks Marc,
We found that it is not possible to attach to a code-first server running in a container from VS 2019.
Regards
-Mohamed
1 Like
It looks like Remote debugging for .NET is actually already enabled for Water (but not Fire, i don’t recall the reason for that now, so i’ll investigate that), but i don’t know the status in Visual Studio.
Does this work for either of you (note that right now i believe that’s restricted to launching, we don’t support attaching remotely for .NET (only native/Island).
Hi Marc,
Unfortunately, we only use Visual Studio.
Regards
-Mohamed
I understand. Using Water might be a temporary workaround until this is exposed in VS, your same Elements project should open there seamlessly, even if just for the purpose of debugging. 
Thanks Marc,
Now is as good a time as any to discuss why we do not use Elements/Water/etc.
We use a lot of third-party components since our team is quite small so we have always been concerned as to whether these tools would integrate seamlessly into your IDEs since the vendors typically only target Visual Studio.
I was never able to find any documentation on this and we never had the bandwidth to experiment with this so we simply never took the risk.
A good example here is that we use DevExpress for most of our GUI while I use a Visual Studio extension that allows me to use the Delphi keyboard mapping since I am too old to get used to the Visual Studio keyboard mapping.
If I can get the same design-time experience with DevExpress using Water and if you support alternate keyboard mappings, I would definitely consider using it.
My other concern is that I have sometimes observed that your tools are ahead of Microsoft’s in terms of language functionality.
While this is a good thing for the projects we do not need to share, it is not quite so good for those that we need to make available for developers outside my team.
My question here is whether there is a way to disable functionality not supported in Visual Studio on a per project basis so we can avoid running foul of this?
On a similar note, if I create a project/solution in Water, can I easily save it in a format that can be used by Visual Studio.
Since we use C# and Java, there are very obvious benefits to be gained by switching to Water but we need to address some of these concerns first.
I look forward to hearing from you.
Regards
-Mohamed
Water does not offer designers at this point, so you would be using Visual Studio for those (see below). All third party libraries and components should work seamlessly with Elements though.
Note that choosing Elements vs Visual C# is a decision separate from using Water vs Visual Studio. You could switch (parts) of your code base to any of the Elements languages, but keep working in Visual Studio, if you prefer.
We don’t currently have an option for this, no, but this is a good idea, i will look into that. Note though that on the4 C# side out extensions are pretty minimal, and mostly in service f other platform’s needs (e.g. multi-part method names). I don’t think you would run into uring many/any of them “by accident”, when working on a code base you want to keep compatible with V isual C#.
Yes, Water, Fire, and Visual Studio use the same .sln and .elements project file format. you can open the same solution back and forth between the different IDEs.
TBH i would worry less about switching to Water, if you are happy with VS as an IDE, and mainly (for now) look whether it makes sense to use the Elements compiler in lieu of Visual C# and/or Oracle’s Java compiler.
Once/if you do, you can always explore using Water, staying in VS, or using both at different times.
Note that for any of the remote debugging discussed here, even once we bring it to Visual Studio, you’d have to be using Elements (ie an .elements project file with RemObjects C#), not Visual C# (.csproj). VC# has its own debuggers that we don’t have anything to do with, and i iahev no idea what their remote debugging story (if any) is…
hth
Hi Marc,
Thanks for the detailed response.
Our code base consists of 3 parts: