We're creating a Visual Studio Debugger extension that needs to launch the application being debugged through a custom launcher that sets up the runtime (not the CLR or Win32) and launch the target application in a new process. In other words, the custom launcher is in charge of creating the new process. In the VS Debugger, one typically launches the debugger by calling VsShellUtilities.LaunchDebugger() and supplying a VsDebugTargetInfo object whose dlo field is set to DEBUG_LAUNCH_OPERATION.DLO_CreateProcess, along with the coordinates of the exe file to be launched and debugged. This doesn't conform to our launching model.
There is also a dlo value DEBUG_LAUNCH_OPERATION.DLO_Custom that seems to be for this purpose (using the clsIdCustom field to indicate the launcher), but the current documentation says that's obsolete and directs us back to DEBUG_LAUNCH_OPERATION.DLO_CreateProcess, but not only doesn't that fit our model, but clsidCustom is used in this case to indicate the debug engine (if it's just a single one).
So, what is the recommended way for us to launch the VS debugger and use our custom launcher to configure and start our runtime (and the application within it)?
According to the Visual Studio API document, it only provide the DLO_CreateProcess to Launches the process. You could use dwClsidCount and pclsidList specify the debug engines to use.
Following example introduce how to call a custom launcher through a VSIX project.
https://code.msdn.microsoft.com/Visual-Studio-Debug-Engine-c2e21c0e
I'm having difficulty porting to a Modern VS2022 but I've been using the VSIX template built of of this Extension which works for VS2017 and VS2019. after some tinkering. This does work for VS2022 but only if you don't tamper with the packages.
https://github.com/microsoft/VSProjectSystem/blob/master/doc/extensibility/IDebugLaunchProvider.md Good luck there's not a lot out there so I thought I'd offer you this gem.
This allows you to make a drop done selection for a project property sheets for debugging. you got to import the targets file which then imports the rules sheet that you create which means you got to make a wizard that creates a custom project.
Related
We already have a working UWP app for x86, x64 and ARM. Everything is fine regarding store certification, all tests are passed, including with .NET native compilation.
We would like to use the Desktop Bridge (similar to what is specified here: https://blogs.msdn.microsoft.com/appconsult/2016/12/19/desktop-bridge-the-migrate-phase-invoking-a-win32-process-from-a-uwp-app/) to add a small .NET 4.6.1 WPF side-kick app to the main UWP (x86, x64) versions. The WPF app has three dependencies(x86 and x64) on some native dll's which are packaged together with the rest of the app.
We added the WPF.exe app and dll's to the existing UWP package (like specified in the above blog post - using xcopy) and built packages for HockeyApp. Locally and functionally, everything works fine for both x86 and x64. Once uploaded to the ms dev center, the Store certification unfortunately fails with the following error:
"Package acceptance validation error: Apps converted with the Desktop
Bridge and that require the .NET Native framework must be pre-compiled
by the .NET Native tool chain"
-- but native compilation is already enabled for UWP Release x86, x64.
We then tried to create a Windows Application Packaging Project (like described here: https://learn.microsoft.com/en-us/windows/uwp/porting/desktop-to-uwp-packaging-dot-net#generate-packages-for-your-desktop-bridge-app) and add both the UWP app and the WPF as dependencies. Then we created a new app manifest and store association (unfortunately it does not seem possible to reuse the existing manifest from the UWP app). We built the app store packages for (x86 x64 Release) and successfully tested everything locally. We then uploaded the package to win dev center and got again the same errors as before
"Package acceptance validation error: Apps converted with the Desktop
Bridge and that require the .NET Native framework must be pre-compiled
by the .NET Native tool chain".
As a follow up we removed the UWP project from the Windows Application Packaging Project and set the WPF app as an entry point. We then built a store package, uploaded it and the .NET native compilation error disappeared. Which is very weird...
Somehow the combination of UWP and WPF (even with native compilation enabled for UWP) causes this certification error. We have a feeling that something is wrong with the packaging.
We would really want to get this combination working or we will have to fall back to having two separate apps: one pure UWP and one packaged WPF companion app which needs to be installed separately. We truly wish we wouldn't have to do this. I'm not sure what we are doing wrong and for the moment I have run out of ideas.
PS: We also know we need to fill and submit a form regarding the restricted capability: full trust. But before we do that we need to be sure that everything else is fine.
UPDATE 4/21/2018
The workaround explained below is no longer needed, and in fact will not be accepted by the Store anymore. The right way to properly package a UWP app with a Win32 extension is to use the new VS Packaging Project, and then create the store package off of that project in VS. Details are in this blog post, see example #3 for this specific case:
https://blogs.windows.com/buildingapps/2017/12/04/extend-desktop-application-windows-10-features-using-new-visual-studio-application-packaging-project/#uvfV1r7937WrSkX2.97
OUTDATED ANSWER BELOW
You are hitting a known flaw in the Store ingestion process for packages that contain a mix of UWP and Desktop .NET binaries. The Store team is actively working on resolving this, so it will work automatically for submissions of this type. In the meantime you can do the following to get unblocked:
Manually create your.appxupload as follows (see screenshots for clarity below):
Go to the output folder for the AppPackage
Select the .appxsym files and the .appxbundle file
Create a new .zip file from those
Rename the .zip file to .appxupload
Resubmit to the Store with the new .appxupload file
I am creating a Coded UI test for our system which runs on Sharepoint 2010. Part of the test sequence is creating a site; Sharepoint's UI for creating sites runs on Silverlight. Therefore, I need to create a Coded UI test for a Silverlight component which is part of out-of-the-box Sharepoint rather then part of our application. When I try to record a test, I get the following message:
No Silverlight controls where detected. Verify that the application under test is built using Silverlight assemblies with a version of 4.0 or greater and that a reference to the Microsoft.VisualStudio.TestTools.UITest.Extension.SilverlightUIAutomationHelper.dll assembly has been added to the project. For more information, see http://go.microsoft.com/fwlink/?LinkId=204562
I have two questions:
1) How can I find out the Silverlight version which Sharepoint components are built against? If they are built against Silverlight version 3.5 or earlier - I suppose the problem is unresolvable?
2) Assuming the previous question is answered - how can I make Sharepoint's Silverlight components reference the SilverlightUIAutomationHelper.dll library? That seems problematic at best to me...
Silverlight version installed on the test machine is 4; Visual Studio Feature Pack 2 is installed.
Thanks.
You can't make SharePoint's Silverlight components reference the automation helper library unless you have the source code and can recompile them. So the answer to your first question doesn't really matter.
You could modify Sharepoint XAPs to simply add Microsoft.VisualStudio.TestTools.UITest.Extension.SilverlightUIAutomationHelper.dll in there. You don't really need the code itself to reference it, it just has to part of the package. The XAP file is just a zip file so you should be able to modify this.
You will have to find where Sharepoint is getting the XAPs from and change the source (obviously you don't want to do this in prod boxes and there's even a license restriction for the Automation dll that prevents you from do it). You could also write a Fiddler AutoResponder to modify the XAP file and add the dll before it gets to the browser. For an example of this have a look at this AutoResponder:
https://bitbucket.org/mamadero/hackingsilverlightdemo/src/2fecb7b59dec/FiddlerAutoResponder
I am trying to get access to the Vector2 objects in a form application, but when I add the refence to XNA.Framework it says that it cannot be found. (But clearly the file exists) Any way to mitigate around this?
I had my build in AnyCPU, thus it was building in x64 natively. I simply right clicked the solution in Solution Explorer, went to Configuration Manager, and created a new build platform. (x86) Builds. :)
I have a C++/CLI library that I would like to use in a Silverlight application. It is supposed to be possible to write code for Silverlight in any .NET language, but so far I've only worked out how to compile C#. Silverlight does not seem to be able to use DLLs compiled for .NET.
I'm using Visual Studio 2010 and Silverlight 4. The only new projects available for Silverlight are C# projects. Porting the code to C# is not a practical option.
How do I compile C++/CLI code for Silverlight?
I think I may have gotten a VS2010 C++/CLI class library project to build with references to (only) Silverlight assemblies.
Update
Ok, it is possible. But it is not nice.
First, you must convince the C++ compiler to NOT load the .NET Framework, using an undocumented compiler switch. But that's not the worst part.
Set your C++/CLI project "Common Language Runtime Support" to /clr:safe
Next, under References, remove all references.
Next, in the C++/CLI project properties, under C++ > Command Line, enter /d1clr:nomscorlib /FU"C:\Program Files (x86)\Microsoft Silverlight\4.0.50917.0\mscorlib.dll"
Now, save the project and exit Visual Studio. Open the .vcxproj in a text editor, and change the framework version setting. You want it to be the same as a C# Silverlight project:
<TargetFrameworkIdentifier>Silverlight</TargetFrameworkIdentifier>
<TargetFrameworkVersion>v4.0</TargetFrameworkVersion>
<SilverlightVersion>$(TargetFrameworkVersion)</SilverlightVersion>
Now, reopen Visual Studio, and build the project. You'll get an error because the compiler auto-generated a file with #using<mscorlib> and the search path finds the .NET Framework version first.
Silverlight,Version=v4.0.AssemblyAttributes.cpp(1): fatal error C1197: cannot reference 'c:\windows\microsoft.net\framework\v4.0.30319\mscorlib.dll' as the program has already referenced 'c:\program files (x86)\microsoft silverlight\4.0.50917.0\mscorlib.dll'
Double-click the error to open the auto-generated file. Replace the path-less reference with e.g. (here's where you put your references, not in the project properties)
#using <c:\program files (x86)\microsoft silverlight\4.0.50917.0\mscorlib.dll>
#using <c:\program files (x86)\microsoft silverlight\4.0.50917.0\System.dll>
#using <c:\program files (x86)\microsoft silverlight\4.0.50917.0\System.Core.dll>
Luckily, the compiler leaves your changes in-place. So you should be good as long as no one cleans your temp directory.
Building should now succeed.
Then, you need to go add the DLL created by the C++/CLI project to your Silverlight application. Note that you can't set up a project reference, because VS2010 still isn't convinced that the C++/CLI is a Silverlight project. So you'll have to browse and add the reference as an assembly file. (And it won't automatically switch between Debug and Release to match the Silverlight application).
Final Notes
I got it to run an empty Silverlight application in Debug mode and stop at a breakpoint in the middle of C++/CLI code. Also the C++/CLI code successfully returned a value to C# and the local variable in C# received the correct value. So I guess it's working.
I went through a bunch more steps trying to make this work, but I don't think they affected the outcome. If you run into errors, though, let me know and I'll try to figure out what I omitted from this answer.
Ben Voigt, thanks for this, it worked for me too.
Also, if your C++ code does anything that is specific to the C++ language (i.e. not entirely IL portable) like using stack semantics for an array, you'll get the following error:
could not find assembly 'Microsoft.VisualC.dll' etc.
If you recompile with the full .NET Framework and then dump the IL code, you'll find references to "''.$ArrayType$$$BY06$$CB_W modopt" or something similar. This tells you where to change the code.
I found that after I installed the Silverlight SDK and it got added to "\Program Files(x86)\Reference Assemblies" I did not have to go through all of Ben Voigt's steps, just changing the project file was enough.
Another note, you can also use:
<TargetFrameworkProfile>WindowsPhone71</TargetFrameworkProfile>
if you want to target Windows Phone (install the SDK first).
Silverlight does not support native C++ libraries, nor any P/Invoke scenarios due to security concerns. If your library is pure .Net you might be able to decompile it with ILDASM and recompile for Silverlight with ILASM.
Silverlight is not a powerful development platform like .NET which is tightly integrated with operating system. First of all silverlight is supposed to run on any operating system, so there is no choice of Native API anywhere in silverlight.
Silverlight also does not support MSIL completely, so there is lot of problem in compiling and recomiping it at IL level.
Can you say more about what kind of C++/CLI code you have? Most Rich internet applications (Silverlight's target) do not include any of high powerful computation, instead they are plain simple HTML+JS alternatives. For powerful graphics, you can use Silverlight's PixelShadder support.
Reflector
What you can do alternatively is,
Compile your C++/CLI to regular .NET DLL, use Reflector to disassemble and generate C# source code from your dll, it may not be perfect, but you will have most of your logic converted back in C#.
I was able Ben Voigt's solution to work with some minor changes in Visual Studio 2013
Here is what I did different.
Unload the silverlight project that you want to reference it in. Right click and choose edit project.csproj
Copy the Target Framework Settings. For me this was
<TargetFrameworkIdentifier>Silverlight</TargetFrameworkIdentifier>
<TargetFrameworkVersion>v5.0</TargetFrameworkVersion>
<SilverlightVersion>$(TargetFrameworkVersion)</SilverlightVersion>
For the compiler switch /d1clr:nomscorlib This was not working for me. Also a reference to mscorlib for silverlight was automatically added to the complied output without specifying it on the command line options. This is how I got around it.
Open the project in Just Deompile
Load the Assembly Editor Plugin
Navigate the tree to the references
Delete the reference to the non silverlight mscorlib from the reflexil menu.
Right click on the top level of the tree for the assembly, and save as under the reflexil menu.
I haven't tested all of the functions, but the ones I have tested so far worked as expected.
Thank you Ben, your post has saved me a lot of time. I was thinking I was going to have to port my library:)
I have a Visual Studio Setup Project that I use to install a fairly simple WinForms application. At the end of the install I have a custom user interface page that shows a single check box which asks the user if they want to run the application. I've seen other installers do this quite often. But I cannot find a way to get the Setup Project to run an executable after the install finishes. An ideas?
NOTE: You cannot use Custom Actions because these are used as part of the install process, I want to run my installed application once the user presses the 'Close' button at the end of the install.
I believe this is one of the real limitations of the Visual Studio installation project. You need to be able to modify the last page of the installation UI but VS.NET does not give you a way to do this. You could modify the tables in the .MSI after it has been built but VS.NET would probably overwrite these changes each time it is built. You may be able to override the last page using a merge module that you include in the installation project. Either way you will need to become familiar with how the UI dialogs are authored in an .MSI and this is not trivial.
You may want to consider switching to a free script based installer or buy a commercial setup authoring application (just don't buy InstallShield for the love of Pete). Take a look at InstallAware (although I have not used it).
I've just found a very easy way which does not require external tools. You only have to add a class file to the main project and a custom action to the setup project.
http://www.codeproject.com/KB/install/Installation.aspx
You also can use custom actions
I've done this for internal apps by creating a VB Script harness that launches the setup executable, waits for it to close, and then launches the second program.
You could also accomplish this with a little more polish using a few Win API calls in a C executable.
You can use MSILAUNCH (though I've only got it to work with MSICREATE).
http://www.cornerhouse.ca/en/msi.html
I managed it by doing invoking the Main method the assembly using the following line:
(typeof(ClassWithinAssemblyToExecute)).Assembly.EntryPoint.Invoke(null, new Object[] {} )
you can do it by custom installer. just add installer class and there u will see many event like after install, before install. just hook up after install and from there run ur exe by process class. i would suggest u google to find more about custom installer.
here is one good link that might help u http://www.codeproject.com/Articles/19560/Launching-Your-Application-After-Install-using-Vis
thanks