MSBuildBinPath for 3.5

  • Thread starter Thread starter Chuck P
  • Start date Start date
C

Chuck P

I have a web deployment project with the following msbuild code.

<Target Name="AfterBuild">
<Exec WorkingDirectory="$(OutputPath)"
Command="$(MSBuildBinPath)\aspnet_regiis.exe -pef connectionStrings
$(OutputPath) -prov HrCustomProvider" />
<RemoveDir Directories="$(OutputPath)/ConfigFiles" />
</Target>

The MSBuildPath points to the 3.5 directory. However in 3.+ the
aspnet_regiis.exe is still in the 2.0 directory. How can I make this work
for 3.5 projects?
 
Hello Chunk,

In order to call the aspnet_regiis.exe located in .NET 2.0 directory, we
can specify the toolset as 2.0 or build a custom toolset according to the
MSDN blog:
Multi-Targeting : How does it work?
http://blogs.msdn.com/msbuild/archive/2006/11/15/multi-targeting-how-does-it
-work.aspx
and the MSDN article:
Standard and Custom Toolset Configurations
http://msdn2.microsoft.com/en-us/library/bb397428.aspx

Please have a try and let me know if it works for you.

Regards,
Jialiang Ge ([email protected], remove 'online.')
Microsoft Online Community Support

=================================================
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).

This posting is provided "AS IS" with no warranties, and confers no rights.
=================================================
 
No it didn't work, the project is 3.5

When I changed the task to:
<Exec WorkingDirectory="$(OutputPath)"
Command="$(MSBuildToolsPath)\aspnet_regiis.exe -pef connectionStrings
$(OutputPath) -prov HrCustomProvider" />

I still get

'C:\WINDOWS\Microsoft.NET\Framework\v3.5\aspnet_regiis.exe' is not
recognized as an internal or external command,
operable program or batch file.


So the question is if I am compiling the latest version of the framework,
how do I get to the appropriate copy of aspnet_regiis.exe so that I can
encrypt the connection strings.

I don't want to hard code framework builds or paths.
 
Thanks, Chunk. I see your points. I think you may try the new registry
syntax in MSBuild 3.5. It allows us to input values by specifying the
registry path:

http://blogs.msdn.com/msbuild/archive/2007/05/04/new-registry-syntax-in-msbu
ild-v3-5.aspx

Therefore, for the .NET 2.0 aspnet_regiis.exe, we can specify its path with
the help of .NET ToolsPath registry:

\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\2.0\@ToolsPath

Please have a try and let me know if it works for you.

Regards,
Jialiang Ge ([email protected], remove 'online.')
Microsoft Online Community Support

=================================================
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).

This posting is provided "AS IS" with no warranties, and confers no rights.
=================================================
 
Is their a way to specify the path to aspnet_regiis.exe that I should be using.
I would rather not hardcode version numbers.
For example,
\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\2.0\@ToolsPath
Has 2.0 hardcoded into the reg path.
 
Hello Chunk,

I believe it is necessary to specify the .NET version number explicitly in
msbuild for the aspnet_regiis.exe tool, because:

1. aspnet_regiis.exe in .NET 2.0 is the latest version of aspnet_regiis so
far. If a newer version of the tool is released together with a new version
of .NET Framework, it is naturally necessary for us to update the msbuild
to use the new aspnet_regiis.

2. Hard-coding .NET version number in registry is much better than
hard-coding the file path to aspnet_regiis.exe. In some machine, the tool
path may be C:\WINDOWS\Microsoft.NET\Framework\v2.0.50727\, however, it may
become C:\WINNT\Microsoft.NET\Framework\v2.0.50727\ in others. Therefore,
the path is not consistent, and I don't think hard-coding the tool path is
a good idea.

If you have any other concerns, let me know.

Regards,
Jialiang Ge ([email protected], remove 'online.')
Microsoft Online Community Support

=================================================
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).

This posting is provided "AS IS" with no warranties, and confers no rights.
=================================================
 
How do webdeployment projects know to goto the 2.0 directory to get the
compiler even though the ToolsVersion is set to 3.5?
 
Hello Chunk,

I see your points, and I think this is a very good question.
Aspnet_compiler.exe is only available to .NET 2.0 Tool directory, like
aspnet_regiis.exe. When ToolsVersion is set to 3.5, how does msbuild know
to find aspnet_compiler in the .NET 2.0, instead of 3.5, tool path?

I my best guess, it is because WDP uses AspNetCompiler Task to perform the
compilation(http://msdn2.microsoft.com/en-us/library/ms164291.aspx) , but
does not use Exec Task to call aspnet_compiler.exe to finish the process.
AspNetCompiler Task also calls aspnet_compiler.exe, but it knows where to
find aspnet_compiler.exe. As to aspnet_regiis, we did not have a
corresponding existed system task. Consequently, we have to use Exec task
and its registry path or full path to call it. I will confirm it with the
developers and get back soon.

Regards,
Jialiang Ge ([email protected], remove 'online.')
Microsoft Online Community Support

=================================================
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).

This posting is provided "AS IS" with no warranties, and confers no rights.
=================================================
 
Hello Chunk,

A msbuild developer has confirmed my guess that the tool path redirection
is done inside the AspNetCompiler task. Would you let me know if you have
any other concerns or questions regarding the issue?

Have a good day!
Regards,
Jialiang Ge ([email protected], remove 'online.')
Microsoft Online Community Support

=================================================
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).

This posting is provided "AS IS" with no warranties, and confers no rights.
=================================================
 
Hi Chuc,

I have exactly the same problem that you presented here, and I was wondering if yours was resolved so I can follow the pattern you used.

jialg - has anything changed since your last writeup? Is aspnet_regiis.exe now developed for .Net Framework 3.5?

Obiman
 
No solution found.
Also if you read the documentation, the description of the environment
variables are different from what is observed in practice.
 
Do you know how gets the path in the task?
You can't use the environment variables. The path they give is not correct.
At least according to the documentation.
 
Hello Chunk

I tested it again and found that I made a mistake in the registry value:
It should be "MSBuildToolsPath", instead of "ToolsPath", in the registry
key: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\2.0\

Therefore, the afterbuild script can be written as:
<Target Name="AfterBuild">
<Exec WorkingDirectory="$(OutputPath)"
Command="$(Registry:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersi
ons\2.0\@MSBuildToolsPath)aspnet_regiis.exe -pef connectionStrings
$(OutputPath) -prov HrCustomProvider" />
</Target>

I'm sorry. Chunk, would you try it again and let me know whether this works
for you now?

And for Obiman, chances are that a new version of aspnet_regiis will be
released in the next version of .NET framework. But for .NET Framework 3.5,
we need to manually redirect it to the aspnet_regiis in .NET Framework 2.0.

Regards,
Jialiang Ge ([email protected], remove 'online.')
Microsoft Online Community Support

=================================================
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).

This posting is provided "AS IS" with no warranties, and confers no rights.
=================================================
 
In my code I caught that and used
<Exec WorkingDirectory="$(OutputPath)"
Command="$(Registry:HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\MSBuild\ToolsVersions\2.0@MSBuildToolsPath)aspnet_regiis.exe
-pef connectionStrings $(OutputPath) -prov HrCustomProvider" />

Still is not what I need, because the version is hard coded, doesn't
automatically give me the build path for the .net version specified.
I wonder how MS gets the path in their build task?

Should the value of $(MSBuildToolsPath) be reported as a bug. The
documentation is different from what the value contains.
 
Hello Chunk,

MSBuild hardcodes the .NET version number for the path of some tools, as
well. For example, the AspNetCompiler task wraps aspnet_compiler.exe, a
utility to precompile ASP.NET applications. AspNetCompiler hard-codedly
redirects .NET framework 3.0 to 2.0 tool path. Chunk and Obiman, I
understand your concerns that hard-coding makes it impossible to adapt the
solution to newer versions of aspnet_regiis. I am sorry for this limit of
msbuild. It is my pleasure to help send a wish to our product designers via
internal channel. You are also welcome to add your supplements to make
Microsoft products easier and more powerful to use by submitting a ticket
in https://connect.microsoft.com/VisualStudio
As we strive to capture any and all product feedback so as to ensure that
we are continuously developing Microsoft products to meet customer needs,
feedback such as yours is always taken very seriously.

Thanks for your understanding.

Jialiang Ge ([email protected], remove 'online.')
Microsoft Online Community Support

=================================================
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
(e-mail address removed).

This posting is provided "AS IS" with no warranties, and confers no rights.
=================================================
 
Back
Top