I borrowed a Program using BinaryFormatter serialization.
An important task for me was to change it in XML serialization.
I developed a converter program which reads the via BinaryFormatter serialized file and saves it in XML.
The program works fine when it's laying in its own project and is executed by hand, but when I call it via the Visual Studio Installer Project it breaks with a SerializationException with the message "The Assembly XXX can not be found".
Why does it work when I execute it manually and automated I get this exception?
Can anybody give me a hint how to solve this issue?
Greets
Henrik
Related
We noticed that on a certain dev machine a Visual Studio (2015 update 3) debug build of a C# solution was generating a $RANDOM_SEED$ file alongside every built DLL.
The content of the file is just a single number e.g.
1443972318
Deleting the file(s) then rebuilding resulted in the file being regenerated, with a different number.
This behaviour was also observed when rebuilding a single project in the solution (one which has only the standard C# project refs/dependencies + System.Management).
Note that running a command line build e.g.
msbuild <sln-file>
did not regenerate the file (for build of complete solution or single project).
After a restart of VS, the file is no longer regenerated.
As far as we know this file name is not used in any of our source code, post build steps or internal dependencies.
There are quite a few dependencies on .NET framework classes, including Random and RNGCryptoServiceProvider, and also external dependencies. We don't have complete source code for all these so it's not possible to check exhaustively which if any of the dependencies are responsible.
This is a bit of a shot in the dark but the question is has anyone seen anything similar to this?
EDIT
I'm not surprised this has been downvoted - I appreciate it is pretty open ended, but as I'm currently not able to reproduce this and as it could have potentially serious consequences (random number generator attack?) I have posted it anyway. If I am able to repro I will of course update here.
I have the same file.
After a short investigation I found guilty:
this file is created by NUnit 3.x test adapter.
(You can check it in AdapterSettings.cs from NUnit adapter source code).
The file is used by NUnit to ensure that we use the same random seed value for generating random test cases in both the discovery and execution processes. This is required because the IDE uses two different processes to execute the adapter. It's not actually required (or created) when running the adapter under vstest.console.exe.
I´m trying to learn the concept of writing events to Windows Event Log using Manifest and I followed the documentation provided by Microsoft.
I´ll describe the steps I took and where it went wrong. Hopefully someone can tell me whats missing or what I'm doing wrong.
Created a Instrumentation Manifest using ECManGen.exe proving information about the provider (C++ Console application), e.g. path to .exe-file. Created channels for all the type (Debug, Administration, Operational, and Analytic). Finally created an event that I
later wanted to write to log. (Also created Tasks and Keywords to organize the Event).
Created a new project in Visual Studio 2013 (C++ Console Application) and included the Manifest (.man) file.
Changed the build settings for the Manifest file to Custom build tool and set command line to mc -v -h . "%(FullPath)" and output to %(Filename).rc;%(Filename).h;.
I then built the project with no problems generating the .rc-file, .h-file, and .bin-files.
After the build I included the all the files to the project generated in Step 4 and rebuild. The rebuild generated the .res-file out of the .rc-file and the resource tab looks like this:
Project
-Manifest.rc
-11
The last step was to register the provider with wevtutil im Manifest.man and this is where I get the error. I received the following error:
Warning: Publisher GGSProvider resources are not accessible.
Failed to open metadata for publisher GGSEventManifest.man. The system cannot find the file specified.
Does anyone see what is wrong or can provide a simple step-by-step guide?
Thanks for any contribution!
The resourceFileName and messageFileName attributes in your manifest file must point to the full path of your dll. You cannot use environment variables in that path.
See http://msdn.microsoft.com/en-us/library/windows/desktop/dd996926(v=vs.85).aspx.
I did the following steps but with an DLL-project and it works fine. Can someone explain this behavior?
The next task is to create an event!
For some reason in VS2010 I can't embed any file into an assembly. These files have their Build Action property set to Embedded Resource as they should, but when the assembly is executed it founds no resources. For example, the following test code:
string[] list = System.Reflection.Assembly.GetExecutingAssembly().GetManifestResourceNames();
string msg = (list.Length > 0) ? "Full" : "Empty";
MessageBox.Show(msg);
always shows "Empty" because GetManifestResourceNames() always returns an empty list.
This issue affects a project using nettiers in which is not convenient for that particular case to include the stored procedures into the DB, so they must be taken from the Procedures.xml file, which BTW is automatically set with Build Action= Embedded Resource after the classes generation, and then of course when a function tries to get any SQL script from it, the program fails.
I also created a couple of test projects where I tried to embed an xml and a gif, always with no success.
Update: The problem seems to be only for C#. I reproduced the test project in VB.Net and there the file does get embedded. I've noticed that in the output window, in the C# case, the compiler command line doesn't include the /resource option (which should be there followed with the name of the file to embed) whereas for the VB case it does appear.
Are there any global settings or configuration files anywhere for C# I should check? (The build options for the project have nothing strange there)
Does anyone have an idea of what may be happening and how to fix this?
Finally, I found the cause:
There was a wrong line inside the Microsoft.CSharp.targets file (located inside c:\WINDOWS\Microsoft.NET\Framework\v4.0.30319). There was a tag written as:
<EmbeddedResourceF Include="#(_Temporary)" />
instead of
<EmbeddedResource Include="#(_Temporary)" />
Writing it right restored the ability to embed files
How that F appeared and why that file got altered in first place, I dont know... Despite being a .NET programmer for several years I just became aware today of the ".targets" files after searching the web about this issue, as never have had the need to look about the MSBuild stuff.
Is there any reference or tutorial for this? And if it's possible, have the javascript file being built only if the file is modified.
You might be able to try this:
http://closurecompiler.codeplex.com/documentation,
But I couldn't get it to work and ended up writing a batch file and hooked it up as a post-build process in the project properties. I've been pretty happy with that solution as it allows me to easily (and in a more standardized fashion) tweak the closure parameters. And any errors from it get reported to you whenever you build.
I've got a nice power-shell driven post-build script that does some magic mumbo-jumbo for pulling all our plugins into the correct location after they're compiled and sorting out thier dependencies with the master-project of the solution.
My problem is, occasionally when I do something stupid, I can end up in a state where my script can't execute it's operation correctly, and throws an exception in powershell with the details of what went wrong.
Is there a way to get these exceptions to pull up to the Visual Studio Error window so that when my post-build fails, vstudio gets a failure notification and nicely formats it in the window alongside all the other warnings/errors?
Edit: This is a clarification to what I'm ideally looking for.
removed dead ImageShack link
Note: If you've landed here looking for how to make custom error messages show up in Visual Studio (when you have control of the error messages) you can see Roy Tinker's Answer to learn how to tailor your messages to show up. If you're interested in catching unexpected errors you can't control, or finding a more complete solution please see the accepted answer.
To create an error, warning, or message that will appear in the Error List window, simply log a message to stdout or stderr in the following format from a script initiated by a pre- or post-build event. Please comment or edit if there is an official spec; this is only what I was able to deduce by trial-and-error and by watching the output of MSBuild. Square brackets denote "optional":
FilePath[(LineNumber[,ColumnNumber])]: MessageType[ MessageCode]: Description
As an example:
E:\Projects\SampleProject\Program.cs(18,5): error CS1519: Invalid token '}' in class, struct, or interface member declaration
For more examples, see the Output window for any error/warning/message that may occur when you run a build in Visual Studio.
Here are two approaches for interrupting the build when a PowerShell script errors.
Use exit() to terminate the PowerShell process
To return a status code from the script which, if non-zero, will show up in the error list, use the following:
exit(45) # or any other non-zero number, for that matter.
This doesn't precisely get the error text onto your error list, but it does terminate the script and get a little something in your error list to indicate which pre- or post-build command failed.
Use a custom MSBuild task to execute the PowerShell script
I spent a little time working out the details of executing a PowerShell script within an MSBuild task. I have a full article with sample code on my blog. Do check it out, as it includes more discussion, and some explanation of how to handle the sample projects. It's probably not a complete or perfect solution, but I got it Working on My MachineTM with a very simple script.
This approach provides line and column precision when reporting PowerShell errors, and even supports the double-click-takes-me-to-the-file behavior we're accustomed to in Visual Studio. If it's lacking, I'm sure you'll be able to extend it to meet your needs. Also, depending on your version of Visual Studio, you may need to massage details like assembly reference versions.
First off, build a custom MSBuild Task in a class library project. The library should reference the following assemblies for MSBuild and PowerShell integration. (Note that this example requires PowerShell 2.0.)
Microsoft.Build.Framework (GAC)
Microsoft.Build.Utilities.v3.5 (GAC)
System.Management.Automation (from C:\Program Files\Reference Assemblies\Microsoft\WindowsPowerShell\v1.0)
Build a task class, and expose a property to specify the path to the PowerShell script, like so:
using System.IO;
using System.Management.Automation;
using System.Management.Automation.Runspaces;
using Microsoft.Build.Framework;
using Microsoft.Build.Utilities;
public class PsBuildTask : Task
{
[Required]
public string ScriptPath { get; set; }
public override bool Execute()
{
// ...
}
}
Within the Execute() method, start the PowerShell run time, execute the script, and collect errors. Use the Log property to log the errors. When finished, close the runspace and return true if the script logged no errors.
// create Powershell runspace
Runspace runspace = RunspaceFactory.CreateRunspace();
runspace.Open();
// create a pipeline and feed it the script text
Pipeline pipeline = runspace.CreatePipeline();
pipeline.Commands.AddScript(". " + ScriptPath);
// execute the script and extract errors
pipeline.Invoke();
var errors = pipeline.Error;
// log an MSBuild error for each error.
foreach (PSObject error in errors.Read(errors.Count))
{
var invocationInfo = ((ErrorRecord)(error.BaseObject)).InvocationInfo;
Log.LogError(
"Script",
string.Empty,
string.Empty,
new FileInfo(ScriptPath).FullName,
invocationInfo.ScriptLineNumber,
invocationInfo.OffsetInLine,
0,
0,
error.ToString());
}
// close the runspace
runspace.Close();
return !Log.HasLoggedErrors;
And that's it. With this assembly in hand, we can configure another project to consume the MSBuild task.
Consider, for example, a C#-based class library project (.csproj). Integrating the task in a post build event requires just a few things.
First, register the task just inside the <Project> node of the .csproj file like so:
<UsingTask TaskName="PsBuildTask"
AssemblyFile="..\Noc.PsBuild\bin\Debug\Noc.PsBuild.dll" />
TaskName should be the name of the task class, though it would seem the namespace is not required. AssemblyFile is an absolute path to the custom MSBuild task assembly, or relative path with respect to the .csproj file. For assemblies in the GAC, you can use the AssemblyName attribute instead.
Once registered, the task can be used within pre- and post-build events. Configure a build event within the <Project> element of the .csproj file like so:
<Target Name="AfterBuild">
<PsBuildTask ScriptPath=".\script.ps1" />
</Target>
And that's it. When Visual Studio compiles the project, it loads the custom assembly and task object and executes the task. Errors raised by the pipeline are retrieved and reported.