I am using VS2019 Professional to develop a Xamarin.Forms app. The project solution consists of the typical head projects which deploy to specific platforms, and the common cross-platform project that contains the bulk of the solution's code. I am trying to find some way, if possible, to run performance tests on the common cross-platform project, which builds to a .NET Standard DLL.
Xamarin currently does not have any tooling available to profile the platform-specific app using the DLL, so I need to find some other way. I have unit tests for this DLL, but there doesn't seem to be any support for profiling unit tests in VS2019. I have tried profiling the vstest.console application that runs the unit tests that test my DLL, but the only option available is to instrument vstest.console, which will do me no good either (obviously don't want to go mucking around with the guts of the test runner!). At this point it seems the only option is to develop an additional test console application and profile that, but I just wanted to check if anyone has encountered a similar use case and found a more elegant solution?
Related
I'm using an application that uses Visual Studio and C# for it's built-in scripting. I want to use NUnit for testing but the environment doesn't understand nuget packages or add-on dll's so it discards anything that isn't source code each time it saves and reloads a project.
I was hoping that I might be able to get around this by including the full NUnit source code in a folder in the C# project and perhaps using something like the lite-runner to run the tests.
Any advise on how to achieve this?
I've a Win32 application written in C# via Visual Studio 2015 and I want to make it portable in order to avoid the installation of .NET framework everytime I deploy my application to clients.
I read this article: the key point of making portable apps seems the use of mscorlib.dll
This method doesn't work, at least for me, despite my effort. I must presume this is not the real way to build an application as portable...?
What are my other options in Visual Studio? Should I rethink my entire application to avoid the use of NET?
Portable applications and packages still require .NET, but in a way you are not using the entire subset available in .NET, which makes it portable among different platforms (Windows Phone, Universal Apps, etc.).
As far as I know the only option you have to overcome the dependency on the .NET Framework, is by compiling your assembly in 'native', which will include all code necessary to run the app on its own.
I'm asking this question due to Silverlight and NUnit, that if you've tried, know they do not play well together. Basic reason being SL code is compiled against the SL framework, and NUnit is compiled against the standard .NET framework.
Anyway, I've got a bunch of classes that are not specific to SL but do reside on the client side. I was thinking about moving them into their own library. Is it possible to configure Visual Studio and/or solution to compile this library both as an SL library AND a .NET library?
My SL client app would reference the SL-version of the library, NUnit would reference the .NET-version.
I'm suspecting at best, this would have to somehow be arranged through the makefile, and the NUnit test project could not reference the project directly, but rather the .dll created.
And other issues like that.
Just wondering what peoples thoughts are on this idea.
Like you were planning to do, you could create SL Class libaray and .Net Class library and have the code in one project and do file link in the other project. This way you do not need to keep two copies of the files. So you can point to the .net class library for the NUnit tests. Just a thought.
Sounds like a job for Portable Class Libraries VS 2012 has built in support and there is an add-on for 2010.
I have a requirement to package up and release a .NET control library across multiple platforms and have a question on how to automate this deployment (or make as efficient as possible) through build scripts and VS2010 configurations.
The control library is to be released as a Silverlight version (separate builds for SL 3.0, 4.0, 5.0) and WPF version (separate builds for .NET3.5 / .NET4.0). I also need to specify release and trial versions of the same libraries. Trial versions will be differentiated in code with a preprocessor statement TRIAL. Both the trial and full version will be compiled in RELEASE mode.
I'm wondering how to achieve this in the most efficient way possible. My VS2010 solution currently has one project for WPF (.NET 4.0) and one separate project for SL (SL 4.0).
Do I need to create further csproj projects for the missing versions, e.g. .NET 3.5 and SL 3.0 and 5.0?
I wish to create one MSI for all Silverlight DLLs and one MSI for all WPF dlls. Do I need to create further MSIs for the versions compiled as Trial? What about separate MSIs for each version of the .NET or Silverlight framework?
Is it possible to achieve the above deployment packaging using build.targets or build scripts?
Basically if I create manually MSIs for all the above combinations and do a full rebuild that would work, but it is also a laborious process when releasing updates. I am looking for suggestions on how to achieve this with build scripts, build.targets, MSI configurations or a combination of the above.
Finally when redistributing the control libraries, installation should ideally result in registration in the GAC.
Any comments / suggestions welcome.
Best regards,
If you are releasing for different versions of the framework, then you will need different projects. You probably could get away with switching the target framework at runtime, but there are so many variables, by the time you get them all figured out and tested, you could have easily created the additional projects.
I think it would be well worth your money to invest in an Installation tool such as Installshield that has built-in support for the rest of the functionality that you desire.
I believe that you should be able to accomplish all of your needs in a single installshield project using various switches and end user keys (to trigger trial or real installs), but you may potentially consider separating trial and real depending on your licensing scheme.
Update
You can also solve this issue through a pure VS2010 solution, it's just more complicated.
Based on your goals, you will need to have a total of 5 projects and each solution will have 2 configurations, one for release one for trial (where the preprocessor define is set).
You might be able to get away with a single build solution that contains all 5 projects since you can reference the output from each project separately within the VS setup project.
On release, you will have to run the build twice, once for release and once for trial, but you can easily automate this with MSBuild.
What we did to ease the release process burden was create a small database to hold configuration information about the products (locations of solutions, project files, and assemblies) and a small UI application that builds the apps by first changing the version everywhere necessary and then building the installer solution through the visual studio build process.
One very important note that I just remembered as I was typing the above: at one point (it may have been fixed), it was not possible to build Visual Studio 2010 setup projects through MSBuild, which is why we went with building through devenv.com.
For posterities sake I'm recording the solution I came up with thanks to competent_tech's very informative answer.
Solved using an msdos batch file as follows.
Dumped the idea of #If Trial switch. Instead component is licensed by licx file so trial build is the same as release build. This means just one solution for dev work which build outputs are derived from
Created a batch file to rebuild Silverlight and WPF output projects with MSBuild, switching toolsversion to create multiple versions
Copied DLLs over to Nuget style directory structure, e.g. Build/lib/net40, Build/lib/sl4, Build/lib/sl5 etc...
Obfuscate built libs in place
XCopy example projects over to Build/examples/
Use Powershell to edit example projects to reference new obfuscated output.
For reference, please see the following questions and answers on removing/re-adding references and editing project files with powershell
I've tried to write unit tests for my monotouch project without any success. The NUnit dlls are not supported in a Monotouch 4 project.
I've tried some weird workarounds that I've found on some sites but nothing seems to work. These workarounds consist in adding monotouch dll to a Nunit project. This procedure seems to work for others on Monotouch < 4 but it don't work for me (Monotouch > 4). The compiler crashes.
So I was wondering if there are some way to write unit tests into a monotouch project?
Alright, what you can do (this is some serious hoop jumping, and kittens die somewhere when you do this...am I missing something?? If not, please Xamarin, make it easier???):
Create a new MonoTouch iPhone project. Add trivial code.
Create a new C# NUnit project. 3.5 or 4.0, doesnt matter. Add trivial test.
Attempt to add a Project Reference to your NUnit project. Fail. Sigh in frustration.
Build your iPhone project (Release or Debug).
Add a reference (oh god, here it comes) to the output of your iPhone project. Yep, point it to the actual resultant, built iPhone dll. Notice how MonoDevelop allows the reference?
Run your tests. You will be pretty constrained on what you can test, but as long as you are not using MonoTouch classes in your target code you may get away with it.
If I get time I will throw a quick example up on GitHub.
This was attempted using:
MonoTouch 4.0.5
Mono 2.10.4
MonoDevelop 2.6 Beta 3
Make sure that your NUnit project's target framework version is .NET 4.