I have a VS 2010 C# "solution"; It creates an .exe file, and a .pdb file when doing a build in Release mode which I use in the InnoSetup build of the installer.
My app uses several .dll's from other vendors (i.e. WinSCP). My question is: do still build the installer using InnoSetup, substituting the new .exe from .NET Reactor for the one created by Visual Studio? The only thing I want to obfuscate using .NET Reactor is my app, not the other vendors.
(I have looked in Google and SO, and did not find an answer.)
You could directly substitute the exe/dll before you build the installer.
In case you want to automatically protect a VS project file output (exe/dll) before it is packaged into your into you setup you could use the .NET Reactor Visual Studio Add-in.
Install dotFuscator then you will be able to add its project type in source code as new project. There you can set output files to obfuscate.
Related
Attempting to create nuget package to upload to our own nuget sever, and would like to eliminate the manual process of creating and editing the nugspec file. Everything I've read, says the setting can be pulled from the project file (if using package reference). And that the settings exist on the Package tab of the project properties window. But that tab is not there.
Using vs 2019, .NetFramework 4.7.2, project is a library, and has been migrated to package reference.
I took an existing project, right clicked the references, and used the migrate option. Package tab is non-existent
I also set the nuget package manager to default to packageReference, and create a new class library.
Package tab also non-existent
The required package (when using non-SDK Style with package reference) nuget.build.tasks.pack has bee added to the references of both projects mentions
Any help would be appreciated
The package tab is only available for SDK style projects. Non-SDK style projects use a different project system in Visual Studio, which doesn't contain that project properties tab. The new project system (on github, the old one is closed source) was initially made to look the same as the old project system, but slowly they're diverging. The Reference/Dependencies node in Solution Explorer is one obvious example, as is the Package tab in the project properties window.
To create the MSBuild properties used by pack, you'll need to manually edit the project file as XML. Within Visual Studio, you need to right click the project in Solution Explorer, select "unload project", now when you single click the project, or right click and select edit, you'll see the project XML. Once done, right click the project again and select reload project. Alternatively, edit it with a text or XML editor outside of Visual Studio, and Visual Studio will detect the change and prompt you to reload the project when you alt-tab back.
My suggestion, however, is to convert your non-SDK style project to an SDK style project. "Standard" class library projects work fine, and I'm not aware of any disadvantages (unless some developers on your team are using Visual Studio 2015 or earlier still), given the non-SDK style project is already using PackageReference. Some other project types might have limited Visual Studio experiences when targeting .NET Framework in an SDK style project. Other project types might not be compatible with SDK style projects at all. However, most people creating NuGet packages are doing so with standard class library projects, which shouldn't have any problems.
There is a "unsupported" tool try-convert to convert non-SDK style projects to SDK style. Personally, I just delete the csproj, create an empty directory, run dotnet new classlib on the console, move the csproj to my existing project's directory, rename the project file, and delete that temporary/empty directory. If you have anything other than .cs files in your project that need explicit entries in the csproj, hand edit the csproj if you're comfortable with msbuild, otherwise load the project in Visual Studio and use the Solution Explorer and Properties windows.
Some people believe that SDK style projects are only for .NET Core or .NET Standard. That's not true, but unfortunately the Visual Studio new project templates give that impression. You will need to create the class library project targeting .NET 5, .NET Standard, or .NET Core. But once the csproj is created, edit the csproj (with SDK style projects it's no longer necessary to unload the project) and change <TargetFramework>net5.0</TargetFramework> to <TargetFramework>net472</TargetFramework>. Another advantage of SDK style projects is it's easy to multi-target, a useful technique to slowly modernize your projects to newer runtimes. Add an s to the XML element name to make it plural, and add extra target frameworks as a semi-colon delimited list <TargetFrameworks>net472;net5.0</TargetFrameworks>. When changing between TargetFramework and TargetFrameworks, Visual Studio should prompt you to reload the project, but I found that it still has some issues. So I suggest closing the solution and opening it again, then everything should work great.
I am getting the following exception while referencing a .Net standard 2.0 project from WPF application developed using .Net framework 4.6.1 project
Could not load file or assembly 'Microsoft.EntityFrameworkCore, Version=2.0.0.0, Culture=neutral, PublicKeyToken=adb9793829ddae60' or one of its dependencies. The system cannot find the file specified.'
Any suggestions?
As of today (using VisualStudio 2017 15.8.4) this still seems to be a common problem:
Transitive dependencies are not correctly handled with the package management format which uses the packages.config file to reference dependencies.
The problem is that VisualStudio 2017 still uses this old package management format by default when you create a new WPF desktop project.
Solution
The solution is to migrate the project references from packages.config file to the new PackageReference node in the .csproj project file.
VisualStudio can do this migration automatically for you. The migration is documented here:
https://learn.microsoft.com/en-us/nuget/reference/migrate-packages-config-to-package-reference
Please note that there is a known issue:
The Migrate packages.config to PackageReference... option is not available in the right-click context menu until NuGetwas initialized.
Another option if your project does not have any package references at all is to change the setting of RestoreProjectStyle to PackageReference in your .csproj file.
https://learn.microsoft.com/en-us/nuget/consume-packages/package-references-in-project-files#using-packagereference-for-a-project-with-no-packagereferences
I hope this helps.
Add reference to Microsoft.EntityFrameworkCore package in your WPF project.
I have developed a WPF application and I need to try it on other computers.
1- I change my project properties to build in release mode and rebuilt project. However, /bin/release folder is empty and it still generates /bin/debug folder.
2- I selected publish and install it on other computers. Funny thing is, the program is not running if that computer does not have Visual C# (.Net Framework, Sql server etc. does not cause a problem)
3- I added a installer and add project output(release) to this application. It says /bin/release/abc.exe couldn't be find.. Changed it to project output(debug) and it builds fine. However, this setup is not even working on my computer..
So my question is simple... How can I publish WPF application in release mode and how can I run them on other computers without installing Visual C#. Thank you in advance
Check properties of your project, and set output folder for Release configuration.
You need .NET 4 framework installed on PC, to run (simple) WPF application.
Should work, when you set your output folder, see 1.
Does anyone know how to specifically include a winforms setup project to be included in the code_drop folder generated when running UppercuTs zip.bat? With the default settings my web applications and WCF services are included, as are the dll's for the solutions core, but not my winforms application/installer
I was just playing around with UppercuT last night, and I ran into the same question.
One tip I found for putting console apps and windows services into the code_drop is to use this Nuget package in your console/windows service projects:
http://nuget.org/packages/publishedapplications
See this for more info:
http://devlicio.us/blogs/rob_reynolds/archive/2011/03/22/published-applications-aka-publishedapplications.aspx
Using this will cause your console/windows service projects to be "published" similary to how a web app is published in the code_drop. However, this isn't what you're asking for, just wanted to point it out if its useful. This also doesn't work for installers.
If your installers are using the default Visual Studio setup projects (.vdproj projects), I haven't tried that, so I can't help there. I do know that MSBuild refuses to build those types of projects (not sure why...), so you might be better off using WiX or another installer technology. You can do an automated build on a vdproj if you run the build by calling devenv.exe directly from the command line, but you can't build those with MSBuild. I did try adding a WiX setup project to my sln, and UppercuT will build the Wix setup project and drop the .msi in the "build_output" folder, but it doesn't copy it over to the code_drop. My thought would be to add a custom post build step to just copy that file over from build_output to code_drop. I haven't had a chance to figure out the logic in the build scripts to see how it chooses which files to copy from build_output to code_drop. If I figure anything out, I'll update this answer.
I have a WPF C# desktop application that will need to be deployed as MSI (Windows Installer deployment, not ClickOnce deployment) in VS2010. My application will generate SQL CE database in run-time, manipulate Excel Workbook, and receive/transmit data from/to COM Port - so I don't know what is the appropriate way to deploy such an application.
I am looking at Windows Installer Deployment Tasks which doesn't help me to get started.
Could anyone show me some resources that give instructions on how to deploy an application as an MSI installer?
If you don't want ClickOnce, then you'll probably need to create your own MSI. In that case, you can use:
The built-in Setup project type in Visual Studio. It does a decent job but has limitations. Works very well if you don't have many dependencies or custom actions.
A commercial tool like InstallShield
WIX (Windows Installer XML)
I've tried both 1 and 3. While WIX has a little bit of a learning curve, it is a very rich way to do what you want to do. There is a fair bit of documentation available and some very nice "out of the box" wizard sequences to handle your standard install scenarios (licenses, feature selection, dependencies, etc). WIX does have some VS integration that works quite well.
You can find out more on WIX at http://wix.sourceforge.net/
Note:
The VS setup project can do custom actions, and install dependencies, but you have to use custom actions. If you want to parameterize the custom actions, then you'll need to find the not-so-intuitive instructions on that topic.
The other limitation of the VS setup project is that the setup project can only be compiled to an MSI by VS (devenv.exe). That means that the MSI cannot be compiled on a build server unless you install Visual Studio there too. This was a show stopper for me, so I switched to WIX and was very happy with the result.
For those like me who found this post after searching high and low for how to deploy an MSI these days, you now need an extension as the visual studio team removed the built in startup project functionality. You now need to download the Visual Studio Installer Projects extension.
See this user voice post for discussion of the removal, and here is a link to the extension.
Useful for people looking for a quick solution to generating an MSI through Visual Studio rather than getting deep into Wix (although if you need more advanced deployment options, definitely go that route).
Configure your WPF application to publish as a ClickOnce application. You can do that in the 'Publish' tab of the project properties.
If you use the 'Publish Wizard' (by clicking on the aptly named button on the properties page) you can specify (on the second page) that the user will install 'From a CD-ROM or DVD-ROM'. This option will produce a setup.exe file in the publish sub-folder of your project output directory. This setup.exe program when launched by your user will install the WPF application. You may choose to include an update functionality (but you don't have to).
The ClickOnce settings also allow you to include additional files (e.g., your SQL CE database file) and pre-requisites if necessary.