I tried to obfuscate a .NET 6 WPF Application with several Obfuscators. ArmDot, Babel, Skater...
Visual Studio creates WpfApp1.exe and WpfApp1.dll. All Obfuscators say, that the Exe is not a managed file. WpfApp1.dll is obfuscated (checked with dotPeek) but the exe wants to download ".net6 Destop" and does not work.
Related
I have been referencing the following tutorial for creating a Setup Project for WiX v3, however, most WiX tutorials on the internet are targeting a C# application as its base project. I am currently building a Visual C++17 Win32 application that I want to deploy (i.e. create a setup *.msi installer) using WiX, given how powerful WiX is.
Unfortunately, adding a reference to my C++ project yields a yellow bang exclamation point:
Moreover, when trying to reference an icon file, for example, in the Product.wxs file using $(var.TimeTrack.ProjectDir)\TimeTrack.ico reports that it is an "undefined predecessor variable." I have tried unloading the WiX Setup Project and tried validating that the yellow banged Visual C++ project reference is referring to the correct path in the *.wixproj file. The include path appears to be correct:
<ItemGroup>
<ProjectReference Include="..\TimeTrack\TimeTrack.vcxproj">
<Name>TimeTrack</Name>
<!-- More not shown. -->
</ItemGroup>
I did a bit of digging and I cam across this StackOverflow posting that indicated that WiX is dependent on .NET framework. In addition, there seems to be a lot of very old postings (e.g. example 1) on this topic and I just am not entirely sure if I am just misunderstanding something here. According to this post, the WiX project cannot refer to any C/C++ code, but this appears to be referring to "Custom Actions," which appear to be an entirely different topic (?).
All in all, am I doing something wrong or is WiX not capable of deploying C++ applications? Is WiX only meant for deploying C# applications?
WiX has a development dependency on .NET but not an install time dependency.
Files are files. WiX doesn't care if they are C, C++, VB, PowerBuilder, Delphi, .NET, NodeJS, Electron or whatever.
The main differences for .NET vs C/C++ is:
1) .NET typically requires you to check that .NET is installed or author a bootstrapper to install it.
2) .NET core can typically be packaged with the app privately without a system wide installation of .NET core.
3) C/C++ typically requires installing the VCRedist via a bootstrapper or statically linking the files into your application.
4) .NET is "AnyCPU" where as C/C++ is compiled for the platform. MSI is compiled for the platoform. This means for .NET a single x86 MSI can deploy a .NET app that might run 32bit or 64bit depending on how it was built. For C/C++ you might need to create a 32bit MSI and a 64bit MSI for your app.
I have a FOSS tool that helps with learning and authoring WiX. You can read about it here:
http://www.github.com/iswix-llc/iswix-tutorials
The tutorials only hav C# examples but pull requests are welcome. Create your C/C++ application and use a postbuild copy command to stage the files to the Installer\Deploy folder and everything else is mostly the same.
I've created an application in C++ using Visual Studio 2010 as my IDE. I used the QT plugin for Visual Studio to create my GUI and also use the VTK and OpenCV libraries. What is the simplest way to deploy my application? I've already tried pasting the DLLs for QT, VTK, and OpenCV in my exe folder and, although this runs on other computers, the formatting and program speed are wildly different than what I get on my computer.
So, you have 2 possible ways:
Static deploy.
Shared deploy.
Description both of them you can find here
As i see the shared deploy is too difficult for you, because you're using heavy libraries.
So, my advice is that satic deploy will be better :)
Please, try to build Qt, libs, and your app static, and we'll see how it will works.
In VS 2010 express there are a few library projects (dlls) attached to the application project. When building the solution the dlls output to bin/Release/. Is there a way to have the .exe output to bin/Release and the dlls to bin/Release/dll?
This requires either a .config file with the <probing> element or implementing AppDomain.AssemblyResolve so that the CLR can find these DLLs. You'll have a deployment problem too, you have to convince ClickOnce to publish these DLLs. Realistically should only attempt this with the retail edition of Visual Studio so you can create a Setup project.
Fwiw: your customer won't mind that the DLLs are in the same folder as the EXE. I think most actually strongly prefer this. I do.
You could always have a post build event on the application project that copies all .dll files to a dll directory.
However the assembly loader will not be able to find the dll file and you application will not start.
I am seeing a strange phenomenon in Visual Studio 2010.
My project setup is this (I inherited this - can't change it any time soon, unfortunately :-():
a Winforms app that uses Crystal Reports X (v10) as its reporting engine; full CR X Developer Edition is installed on my dev box
several Webforms apps that use Crystal Reports XI (v11) as their reporting engine - cannot install CR XI full version, since it clashes with CR X Dev Edition....
In order to make things work on our build server, I also created a Library folder inside the Winforms app's project directory with the CR X runtime files I need, as well as a Library folder inside the web app's project directory with the CR XI runtime files.
In VS 2008, I was able to pick the necessary assemblies from the respective library folder in my Winforms projects (several class libraries etc.), and in my web apps. Everything worked great.
When I updated to Visual Studio 2010, now suddenly I'm seeing:
in my Winforms apps, all the references to CR X runtime files are being automagically updated to use the CR X files from the GAC - this is not what I want! It doesn't help if I delete those references and re-add them again by browsing to the Library folder - when I pick them, VS2010 seems to automagically conver them to GAC references again...
in my Web apps, things get even worse: when I pick the CR XI runtime assemblies from the Library folder, again, VS2010 automagically seems to detect there are similar files (same name, but different versions) in the GAC and uses those files instead - now my web apps don't work anymore.....
What the h*** is going on with VS 2010 here?? Why can't it leave my selections alone and let me choose my runtime files from a Library folder instead of insisting on going to the GAC?? What has changed between VS 2008 and VS 2010 in this respect?? Does anyone have any insights into this??
It may be useful to either
(1) go to Tools\Options\Project&Solutions\Build&Run and change MSBuild verbosity to 'diagnostic' and then build and in the Output window see how the MSBuild reference resolution logic is working for those assemblies. That is, if VS hasn't already done something ridiculous to the underlying .csproj file
(2) compare the XML in the VS2008 project file versus the VS2010 project file to see what's in the <Reference> nodes
A wild speculative guess: the VS2010 project is targeting ".NET 4.0 Client" (rather than ".NET 4.0 (full framework)", and the libraries need the full framework, and MSBuild sees this dependency and is using fallback logic.
I'm trying to create an absurdly simple shell extension in C++ using Visual Studio 2010, but I can't even seem to get the examples out there to work as a starting point.
I'm using Windows 7 x64.
I've tried this Visual Studio template, but once I get the template to work in VS2010, I have a host of errors that I'm not sure how to fix.
I've tried The Complete Idiot's Guide to Writing Shell Extensions, and once the demo compiles all the right registry settings etc. are created but no context menu appears.
I've looked at this C# COM Interop example, but I've been left confused as to whether it is safe to use C# thanks to this article*, but it looks like I might be OK if I use .NET 4 because it supports in process side-by-side CLR hosting.
in short: historically two versions of .NET cannot run in the same process, and the way shell extensions work is they inject themselves into a process. So if .NET 3.5 gets injected into a .NET 2 process - bang
So, can I use .NET 4.0 now?
Is there a working, downloadable, VS2010 solution that adds a simple shell extension?
I used to be not so bad with C++ back in the day, but after years of moulding to .NET I'm quite rusty, and as such, fiddling with the details to fix the host of errors I'm getting on the existing examples is proving... fiddly!
I could really do with a clean slate to start with that I can break myself and figure out what I did wrong!
I struggled with this for a while and had limited success with the code project article due to x64 issues and SDK differences.
I recently picked the project back up and started over using the MS all-in-one code sample and I am very pleased. It makes a simple example context menu and x64 works out of the box: http://code.msdn.microsoft.com/windowsdesktop/CppShellExtContextMenuHandl-410a709a
To get it running on your machine:
download the code via the all-in-one sample browser or use the direct link.
Open project in VS under admin rights
switch build config to x64 and build it
Kill all explorer sessions
Locate the new dll and run regsvr32.exe .\CppShellExtContextMenuHandler.dll
open explorer again and right click a .cpp file to see the new menu
remove it by running same command with /u flag
My next step is to get debugging working and I think this may do the trick: msdn
On Windows 7 x64 for a C++ extension you need to build it as an x64 project. In Visual Studio 2010 there is an option on the ATL Wizard to create a shell extension project that provides preview window support, thumbnails and Windows Search support. I recently used this and once built, nothing seemed to happen. However, switching the project configuration to build an x64 dll got it working.
With regards to using .Net - Explorer now launches plugins in a separate sub-process. So loading a shell extension that links to .net 4.0 does not contaminate everything with that version of .net as only the hosting subprocess will actually load that CLR. You can see this using a preview extension as a new process (prevhost) gets launched to contain this.
I got this one working: http://www.codeproject.com/Articles/174369/How-to-Write-Windows-Shell-Extension-with-NET-Lang
Make sure you use the right RegAsm.exe for de/registering it:
32-bit platforms: Compile for x86/Any CPU. Use C:\Windows\Microsoft.NET\Framework\vXYZ\RegAsm.exe.
64-bit platforms: Compile for x64/Any CPU. Use C:\Windows\Microsoft.NET\Framework64\vXYZ\RegAsm.exe.
(XYZ is the version of the .NET Framework you used for compiling.)
Note, however, that Microsoft recommends against using .NET for shell extensions.
The short answer to your 'can I use C#' is no. This is from Microsoft’s Guidance for Implementing In-Process Extensions. "One runtime of particular note is the common language runtime (CLR), also known as managed code or the .NET Framework. Microsoft recommends against writing managed in-process extensions to Windows Explorer or Windows Internet Explorer and does not consider them a supported scenario."
The problem arises because only a single version of .NET can be used in an application and there is no way to enforce that limitation if multiple .NET extensions are in use.