So as I sit here pondering this idea that I have, I am curious on where to even start if this is possible. I work for Salesforce (specifically supporting the Marketing Cloud application - a web app). We have several publicly available API's (SOAP and REST) for third party integrations to take place and impact data within the Marketing Cloud environment. So, to keep this on a simple level and not go into detail around the Marketing Cloud, is it possible to somehow write a sort of plug-in for Visual Studio that will, upon certain actions in Visual Studio, make API calls to a third party (in this case, I'm talking about Salesforce Marketing Cloud). My end goal is for Visual Studio to be able to initiate a custom action (API call to a third party) whenever a certain action happens from within Visual Studio. I hope this makes sense! Where would I start with this if this is possible?
Not sure if this is for VS or VS Code, will assume VS Code as it is compatible with both Windows and Mac.
What you're asking for should theoretically be possible because of the structure of the Electron app which VS Code is built on. Also it useses NodeJS.
I'm a Mac user, but when I used VS Code, I found this tutorial helpful for getting started:
https://www.youtube.com/watch?v=qV0e7LSQOIE
Also the docs are pretty helpful too:
https://code.visualstudio.com/docs/extensions/overview
And there is this little boilerplate I found online too:
https://github.com/mrmlnc/vscode-plugin-boilerplate
Related
I have a solution which contains two microservices and an API gateway. While debugging, the solution requires to run again and again to get insights or fix bugs.
I have tried dotnet watch run but with this I can attach debugger to one project at a time.
Hosting applications on IIS also requires to copy the files to folder every time for small changes as compared to in .NET Framework where it was easier to host applications on localhost and attach to process.
Currently, I have been debugging it using visual studio with multiple startup projects.
Since pressing F5 constantly is repetitive and hectic so is there any other way around to debug multiple projects using dotnet watch or IIS or anything else?
ctrl+F5 can run multiple, but it will not debug. Other solution try run multiple VS studio, but I'm not sure
There is possibly another way. I was also had issues running multiple projects to debug microservices.
I explored a few possibilities:
Docker - didn't help and ate more memory (if our whole stack was .net core this might be the goto)
Auto starting VS projects with a script (better but not quiet the level of control we needed)
Researched all the things that people said (use logging, do tests etc, all of which ignore the fact that we don't all have perfect codebases to work in)
Finally I created something that works well for our team, and maybe it'd work for you?
Dev Launcher is a simple command line utility that you configure with your project information. It's currently aimed at handling .net full framework, runs in (Visual Studio) and .net core runs with (Visual Studio or dotnet run). It is configurable and I'm guessing a person could get it to work with other IDE's such as VS Code, though I haven't tried it.
The main concept is you first choose the projects you'd like to open for debugging. These projects will open in the IDE which is configured (Defaults to Visual Studio). Then you choose the supporting microservices that you'd like to run in the background. If these are written in .net core they will run in a console window, freeing the memory that would normally be consumed by the IDE and debugger.
Curious to see if that'd be helpful for your situation. Also curious what other ideas people have to make debugging multiple microservices better...
What tools are you using for CRM plugin development?
I used both "Dynamics 365 Developer Toolkit" and "Dynamics 365 Developer Extensions" previously. Unfortunately, The "Dynamics 365 Developer Toolkit" no longer works reliably for me in VS 2019 (yes, I followed the steps to update the vsix file). I looks like Jason Lattimer's has stopped making the "Dynamics 365 Developer Extensions".
Thanks!
Personally I use none, but rely on an Azure DevOps pipeline to deploy everything.
For client side development I heavily use Fiddler 4 with auto responder rules with a local webpack devserver. I am not sure how to improve this process much more.
For serverside Plugins I prefer using ILMerge Build Tasks (check nuget) and separate the IPlugin interface implementation from my code so I can easily write unit tests for that. I do not use testing libraries like EasyRepro or XrmFakeEasy. I don't think they add a big benefit and more or less negate one of the best effects of unit testing. Creating good testable code.
For plugin deployment I currently use spkl by Scott Durrow and it is working fine so far.
For generating early bound classes I use a custom .bat file that actually just calls the CrmSvcUtil.exe with a couple of extra .dll files that helps creating enums instead of optionsets.
I am not a huge fan of toolkits or templates that dictate how you have to write your stuff, because most of them embrace bad programming patterns. For example the XrmToolkit forces you to use a certain folder structure for your clientside scripts to not mess up your crm system and so on.
XrmToolkit is a commercial Dynamics 365/CDS development add-on that is actively maintained and supports Visual Studio 2019.
I have been relying on it for years to assist with generating proxy classes, registering and publishing plugins, publishing web resources on save, etc.
I have no affiliation with XrmToolkit.
You can use Microsoft.net framework with visual studio or visual studio code for implement dynamics 365 plugins and register that in plugin registration tools.
• Write a plugin
• Register a plugin
I have developed a sharepoint 2010 visual webpart application with multiple visual webparts using visual studio 2010. I am able to deploy it successfully to Production server using commands given below:
Add-SPSolution c:\sp\MySampleProject.wsp
Install-SPSolution -Identity MySampleProject.wsp -WebApplication https://MYURL -GACDeployment
In my visual webparts, I am referencing some of the sharepoint custom LISTs and doing add/update operations with list items. Now If I deploy the webpart manually using the commands above, I also need to create all of the reference LISTS at production server. For this what I do, i just take list template to production and replicates the list structure to production.
Is there any way, I could create a auto installer(EXE SETUP or MSI) that should be able to create all the lists as well as deploy all of the webparts to production server. I know this can be done, as whenever we purchase some third party webparts from other vendors, they provide us MSI or other executables that we just execute, and it does everything for US. But I am not sure how to do it. What tool they use to develop these kind of installers.
Any HELP or suggestion ? ?
CodePlex may have the utility you need. Microsoft doesn't provide an out of the box solution that I'm aware of. From the looks of it, this may be what most 3rd party developers use as well
http://sharepointinstaller.codeplex.com/
Your feature should be creating these dependant lists/list items on activation, then add the web part to the gallery. This is exactly what feature activation is for!
In reality, I would have them as two features (both scoped to the site collection level). One feature creates the lists/list items, and the second deploys the web part. The second would be dependant on the first. The first one could be a "hidden" feature if you wish.
Whether or not you remove those lists on deactivation is up to you. There's good arguments either way.
Almost all of our Windows projects consist of a WCF windows hosted service and then a WPF client application. All of these have usually been split into two different solutions, one for the service, one for the client. This was done for various reasons, but we recently were looking at possibly putting them all together on a new project, which we did. This would mean not having to run two copies of Visual Studio and make it easier for various other things.
Our concern now is being able to edit the WPF client while debuging the service. Many of the developers will keep the service running a large part of the day when making changes in the client. But it looks like with this setup, when you start debuging the service, Visual Studio will not let you edit any of the other code in the solution.
Is there a way around this, so that you could have the service running whenever you want, and still be able to edit the WPF and CS files in the other project? Or should these two parts stay in two separate solutions?
You'll want two instances of Visual Studio: one doing the debugging of the service and the other one for coding.
You could also imagine having the service running without the debugger attached, and only attach it manually when you're ready to launch/debug the client you were working on.
Why should one go for Windows Installer XML (WiX) when we have in built .net MSI installer?
It would take me hours to rant about everything I hate about VDPROJ. I won't because in my (expert) opinion it's already settled law that VDPROJ sucks. If your install is so simple that you haven't noticed any problems, then be my guess and stick with it. But if you already find yourself fighting the tool trying to get it to do things it doesn't do, then take my advice and dump it fast for WiX.
10 things I hate about VDPROJ
No MSBuild Support. Sure, you can call devenv from the command
line but it's not as good.
No exposing of the critical concept of
a component. Every file/reg key is a keyfile of it's own component.
No effective way to fully exclude automatic dependency scanning.
Shortcuts are always Advertised
No way to describe a service.
No way to describe many things which leads to overuse of custom
actions.
No way to fine control the scheduling / execution of
custom actions. Too abstracted.
Abstraction is wrong. Deferred
CA's are scheduled with Impersonation which breaks on Vista.
Various limitations lead you down a path of massaging the built MSI
during postbuild to get around all the limiations. Results in a
very poor build automation hacks.
Merge Module directory tables
are authored incorrectly.
100 other things suck that I'm not
remembering right now.
The introduction of WiX tutorial gives the basic idea about WiX advantages comparing to other setup development tools (including VS setup projects):
declarative approach
unrestricted access to Windows
Installer functionality
source code instead of GUI-based
assembly of information
complete integration into application
build processes
possible integration with application
development
support for team development, both
in-house and third-party
free, open source
Hope this helps.
Visual Studio deployment packages can only be built by visual studio. They cannot be built using plain MSBuild command lines, which makes them less than ideal for e.g. build servers.
All the above answers have included most of the annoying features of Visual studio setup projects (.VDPROJ), one thing that most people have missed.
.VDPROJ file format is such that, and if we make a small
change to one single entry it completely rewrites all the entries
within which makes it impossible to merge changes from 2 different
branches.
Some of us don't want to use / can't use the .NET installer.
Some of us don't want to have to install Visual Studio to distribute a program, written in, say, Borland Delphi. WiX and .NET have nothing to do with one another.
WiX provdes a much more complete feature set than the .NET installer.